Arqly
Sign in
#08Build a document store (MongoDB-style)
stub
Schemaless documents that still behave like a database. Build a system that stores JSON/BSON natively, ships replica sets with primary elections, shards a collection by key range or hash, and keeps secondary indexes consistent under write — and feel exactly where 'flexible schema' turns into 'silent inconsistency'.

Build a document store (MongoDB-style). Schemaless documents that still behave like a database. Build a system that stores JSON/BSON natively, ships replica sets with primary elections, shards a collection by key range or hash, and keeps secondary indexes consistent under write — and feel exactly where 'flexible schema' turns into 'silent inconsistency'.

This problem is a stub. Suggested approaches haven't been authored yet — ask the staff engineer in the right panel for any stage and they'll generate one tuned to your draft.
Reading: MongoDB Architecture Guide (mongodb.com whitepaper) · MongoDB Manual — Replica sets, Sharding, Read/Write concerns · WiredTiger architecture doc (storage engine internals) · MongoDB blog — Causal consistency in MongoDB 3.6+ · Kleppmann — Designing Data-Intensive Applications (Ch. 2 — document vs relational) · Jepsen — MongoDB analyses (multiple)
BSON on-disk format + WiredTiger storage layer
replica sets: primary, secondaries, arbiter, election protocol
oplog as the replication log (idempotent ops)
read / write concerns + journal commits
sharded clusters: chunks, shard key, balancer
scatter-gather queries (no shard key in predicate)
secondary indexes — B-tree per index per collection
consistency: linearizable reads vs majority vs local
the embedded-document trade (denormalize vs join)
transactions across shards (2PC over the oplog)
No scenes authored for this problem yet.