Document Store (MongoDB, DynamoDB)

1. What Is It?

A document store is a NoSQL database that stores data as semi-structured documents — typically JSON, BSON, or XML — rather than rows in fixed-schema tables. Each document is a self-contained unit that can hold nested objects, arrays, and mixed types. The schema is flexible: two documents in the same "collection" (MongoDB) or "table" (DynamoDB) can have entirely different fields.

Without document stores, teams that need flexible or evolving schemas are forced into painful SQL migrations every time the data model changes, or into denormalized "schemaless" hacks like storing JSON blobs in VARCHAR columns. Document stores solve this natively: add a new field to one document, and no migration is required. They also shine for hierarchical data (e.g., a user profile with embedded addresses, preferences, and tags) where SQL would require 4-5 JOINs to reconstruct what a single document fetch returns instantly.

2. How It Works

Core Mechanism

A document store maps a document ID (primary key) to a document (a rich, nested data structure). Internally, documents are grouped into collections (MongoDB) or tables (DynamoDB). Unlike relational databases, there's no enforced schema — the database stores whatever fields the application provides.

Write Path:

1. Application sends a document (INSERT / PutItem)
2. The storage engine serializes and writes it to disk (WiredTiger in MongoDB; a distributed SSTable-like store in DynamoDB)
3. For durability: MongoDB writes to the WAL (journal) before acknowledging; DynamoDB replicates to 3 AZs before acknowledging
4. Secondary indexes are updated asynchronously (DynamoDB GSIs) or synchronously (MongoDB)

Read Path:

1. Application queries by _id / partition key → O(1) lookup via a hash index, or O(log n) via a B-tree index
2. Or queries by non-primary fields → full collection scan unless a secondary index exists
3. For embedded arrays and nested fields, the query engine filters in-memory after fetching candidate documents

Document Store: Read by Primary Key

Application
    │
    ▼  GET /users/u123
 Query Engine
    │
    ▼  Hash(_id) → Shard/Partition
 Storage Node
    │
    ▼  B-tree lookup → Page cache (RAM) or Disk
 Returns document (single round-trip, no JOIN)

Mermaid: Architecture Diagram

-+ResetFullscreen

Data Model Example

MongoDB — User Profile Document:

Copy
{
  "_id": "u_7f3a91c",
  "username": "alice",
  "email": "alice@example.com",
  "addresses": [
    { "type": "home", "city": "San Francisco", "zip": "94105" },
    { "type": "work", "city": "Oakland", "zip": "94612" }
  ],
  "preferences": {
    "notifications": true,
    "theme": "dark"
  },
  "tags": ["premium", "beta-tester"],
  "created_at": "2024-01-15T08:30:00Z"
}

DynamoDB — E-commerce Order:

Copy
{
  "PK": "USER#u_7f3a91c",
  "SK": "ORDER#2024-01-15#ord_abc123",
  "status": "shipped",
  "items": [
    { "sku": "PROD-42", "qty": 2, "price_cents": 1999 }
  ],
  "total_cents": 3998,
  "shipping_address": { "city": "San Francisco", "zip": "94105" }
}

3. Variants & Comparisons

Document Store Flavors

MongoDB vs. DynamoDB Head-to-Head

4. When to Use It (and When NOT To)

Use Document Stores When:

• Flexible or evolving schema: Products/catalogs where different items have different attributes (shoes have sizes, books have ISBNs). Schema changes are frequent during development.
• Hierarchical/nested data: User profiles with embedded addresses, preferences, and metadata — data that belongs together should be stored together (avoid JOIN overhead).
• Read-heavy workloads with denormalization (storing related data together in one document, even if it means duplicating some data, to avoid expensive JOINs): You can pre-embed related data and fetch it in a single read. At ~50K+ QPS read, avoiding JOINs matters.
• Horizontal write scale needed: At 10K+ writes/sec sustained, sharded document stores outperform single-node SQL. MongoDB sharding or DynamoDB auto-scaling handle this natively.
• Unpredictable or bursty traffic (DynamoDB on-demand mode): Pay per request, no capacity planning.

Do NOT Use Document Stores When:

• Complex multi-entity JOINs are frequent: If your queries routinely JOIN 3+ entities with arbitrary filter combinations (e.g., ad-hoc analytics), SQL wins. Document stores punish you for querying non-indexed fields.
• Strong consistency across entities is required: Financial transactions (debit account A, credit account B) need distributed ACID. MongoDB 4.0+ supports this, but at performance cost; DynamoDB TransactWrite is limited to 25 items. Prefer PostgreSQL or CockroachDB.
• You don't know your access patterns yet (DynamoDB specifically): DynamoDB requires upfront schema design around access patterns. If requirements are volatile, MongoDB or SQL is more forgiving.
• Document size exceeds limits: MongoDB 16 MB cap / DynamoDB 400 KB cap. Large binary blobs belong in object storage (S3), not documents.

Decision Triggers

5. Real-World Usage

Foursquare → MongoDB

Foursquare stores venue and check-in data in MongoDB. Their venue documents naturally embed tags, categories, and tips — data that would require multiple SQL tables. At peak they handled millions of check-ins with MongoDB's horizontal sharding. The key insight: venue data is read far more than written, and embedding related data eliminates JOIN latency.

Samsung → DynamoDB

Samsung uses DynamoDB as the metadata index for petabytes of mobile app backups (voice recordings, notes, contacts stored in S3). The key metrics: low-latency key-value lookups, automatic scaling for unpredictable traffic from hundreds of millions of devices, and no ops burden. Samsung achieved 30%+ cost reduction by migrating cold data to DynamoDB Standard-IA tables.

Lyft → DynamoDB

Lyft runs 100+ microservices on DynamoDB, including GPS coordinate storage for all rides. The ride-tracking use case is a perfect fit: writes are key-based (ride ID), scale is enormous and bursty, and the simple access pattern (get ride by ID) aligns with DynamoDB's partition-key model. DynamoDB's single-digit ms latency supports real-time driver location updates.

6. Interview Cheat Sheet

5 Sentences to Show Deep Understanding

1. "Document stores trade query flexibility for horizontal scalability — by embedding related data in a single document, you eliminate JOINs and can shard by document ID, but you lose the ability to query arbitrarily across entities without secondary indexes."

2. "The key design decision with DynamoDB is access-pattern-first modeling: because it can only query efficiently by partition key or GSI, you must define your access patterns before designing the schema — the opposite of SQL's query-anything model."

3. "MongoDB added multi-document ACID transactions in v4.0, but they come at a performance cost — they're a tool for correctness on critical paths, not a replacement for careful denormalization in the hot path."

4. "At scale, document stores shine for write-heavy workloads by sharding on a high-cardinality key (user ID, order ID) — but hot partitions are the enemy: a celebrity user generating 100x traffic needs composite shard keys or read replicas."

5. "DynamoDB's single-digit ms latency claim is measured server-side — real end-to-end P99 includes network latency, SDK overhead, and potential throttling if RCU/WCU limits are hit."

Common Follow-Up Questions

Q: When would you choose MongoDB over DynamoDB? A: When you need rich ad-hoc querying (aggregation pipeline, full-text search), schema flexibility during development, or multi-document ACID transactions. DynamoDB wins when you need zero ops, auto-scaling, and have well-defined access patterns.

Q: How do you handle a many-to-many relationship in a document store? A: Two approaches: (1) embed IDs of related entities and resolve them at application layer (2 queries); (2) use a reference pattern where a separate "join document" stores the relationship. For DynamoDB, the single-table design pattern handles this with overloaded partition/sort keys.

Q: What's the thundering herd problem with DynamoDB and how do you solve it? A: A sudden spike of reads/writes to one partition key exhausts that partition's throughput. Solutions: (1) add a random suffix to spread hot keys across partitions; (2) use DAX (DynamoDB Accelerator) as a write-through cache for hot reads; (3) use on-demand mode to absorb spikes.

Q: How does MongoDB ensure durability? A: Write-Ahead Log (journal) + replica set. MongoDB writes to the WiredTiger journal before acknowledging a write (with j:true). The replica set (3 nodes) ensures durability if the primary fails — elections happen in <10s via Raft-like consensus.

Connections to Other Building Blocks

• Caching (Redis): Document stores are often paired with Redis as a look-aside cache. MongoDB reads can be slow on cold data; cache hot documents by ID.
• Sharding: Both MongoDB and DynamoDB shard by partition key. Choosing a high-cardinality, uniform-distribution shard key prevents hot partitions (see Sharding & Partitioning building block).
• Message Queues: DynamoDB Streams (change data capture) can trigger Kafka/SQS workflows — useful for event sourcing patterns where document writes fan out to downstream services.
• Search Engine (Elasticsearch): Document stores lack full-text search. A common pattern: write to MongoDB/DynamoDB as the source of truth, stream changes to Elasticsearch for search queries.
• Wide-Column Stores: DynamoDB's data model is closer to wide-column (Cassandra) than to true document stores — partition key + sort key + sparse attributes. The difference is query flexibility: DynamoDB allows nested JSON values; Cassandra does not.