Document Store

1. The application service serializes an aggregate—say a customer profile with nested addresses, preferences, and order history—into a single self-describing JSON/BSON document rather than fanning it across normalized tables.
2. The document store driver writes the document into a collection, tagging it with a schema version field so evolving shapes coexist without a migration.
3. The storage engine persists the document to a partitioned collection, using the shard key to route writes and co-locate related documents on the same node.
4. Secondary indexes are built on frequently queried fields—including nested paths and array elements—so predicate and range queries avoid full collection scans.
5. A query API executes rich filters, projections, and aggregation pipelines server-side, returning only the fields each consumer needs.
6. Read replicas serve low-latency reads and analytics offload, while the primary handles writes; the client tunes read/write concern to trade consistency for latency.
7. Downstream consumers—search indexers, event streams, or a change-data-capture feed—subscribe to the change stream to propagate document mutations in near real time.

• Schema flexibility vs the loss of database-enforced integrity, pushing validation into the application.
• Single-document read performance vs data duplication and manual consistency across embedded copies.
• Horizontal scale via sharding vs the difficulty of changing a shard key and cross-shard query cost.
• Fast iteration vs weaker support for ad-hoc joins and normalized reporting.

A media streaming company stores each user's viewing profile as one document: nested watchlists, per-device playback settings, personalization signals, and A/B flags. When product adds a new preference, engineers simply write the new field—no downtime, no ALTER TABLE across billions of rows. A change stream feeds the recommendation pipeline and a search index whenever a profile mutates, and sharding by user ID keeps reads under 10ms as the catalog and audience grow globally.

• Atomicity boundary: Writes are atomic only at the single-document level; multi-document transactions exist but incur cross-shard coordination cost, so design aggregates so one document equals one consistency boundary.
• Change stream semantics: Change feeds deliver at-least-once and can emit duplicates or gap on failover; consumers must be idempotent and checkpoint a resume token to replay from the last processed mutation.
• Schema evolution: Since documents are self-describing, old and new shapes coexist forever—write migration-on-read logic keyed on the version field, and backfill lazily rather than assuming every document has new fields.
• Index and document limits: Watch per-document size caps and unbounded array growth; embedded arrays that grow without limit bloat documents, slow updates, and eventually breach size ceilings—cap or bucket them.
• Cost and performance drivers: The bill is driven by index count, working-set RAM, and write amplification from index maintenance; every secondary index slows writes, so prune unused ones and cover hot queries deliberately.
• Shard key commitment: The shard key is effectively immutable and dictates hotspotting—avoid monotonically increasing keys, and monitor chunk balancing, jumbo chunks, and cross-shard scatter-gather query latency.
• Operational chores: Reclaiming space after large deletes often requires compaction, and read replicas add replication lag—tune read concern for consumers that cannot tolerate stale reads.