Bird
Raised Fist0

Document Databases - MongoDB Data Modeling Patterns at Scale

HLDmediumInterview freq: medium
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
Client Application

Send query for user profile data

Query requests embedded and referenced fields

Protocol:HTTP
BeforeUser has profile data request ready to send
AfterQuery sent to Mongos Query Routers
Mongos Query Routers

Parse and route query to shards

Determine shards based on shard key and forward query

Protocol:MongoDB Protocol
BeforeQuery received from client, routing not done
AfterQuery dispatched to appropriate Replica Sets
Replica Sets

Execute query on shards

Retrieve embedded documents directly from primary

Protocol:Internal MongoDB
BeforeQuery received, data not yet fetched
AfterEmbedded documents retrieved from primary nodes
Reference Pattern with $lookup Aggregation

Perform $lookup join across collections

Aggregate referenced documents from other shards

Protocol:Internal MongoDB Aggregation
BeforeEmbedded data retrieved, references unresolved
AfterReferenced documents joined with embedded data
TTL Indexes

Expire outdated documents asynchronously

Remove expired session or cache documents

Protocol:Background MongoDB process
BeforeExpired documents present in collections
AfterExpired documents removed automatically
Mongos Query Routers

Aggregate results and send response

Combine embedded and referenced data into one result

Protocol:MongoDB Protocol
BeforePartial results from shards ready
AfterComplete query result sent to client
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│    Client Application │
└─────────────┬─────────┘
              │ HTTP Query
              ▼
┌───────────────────────┐
│  Mongos Query Routers │
└─────────────┬─────────┘
              │ MongoDB Proto
              ▼
┌───────────────────────────────┐
│    MongoDB Sharded Cluster     │
│ ┌───────────────┐             │
│ │ Replica Sets  │             │
│ │ ┌───────────┐ │             │
│ │ │ Document  │ │             │
│ │ │ Embedding │ │             │
│ │ │ Pattern   │ │             │
│ │ └───────────┘ │             │
│ │ ┌───────────┐ │             │
│ │ │ Reference │ │             │
│ │ │ Pattern   │ │             │
│ │ │ with      │ │             │
│ │ │ $lookup   │ │             │
│ │ └───────────┘ │             │
│ └───────────────┘             │
│                               │
│ ┌───────────────┐             │
│ │ TTL Indexes   │             │
│ └───────────────┘             │
└───────────────────────────────┘
Design Rationale

This architecture illustrates how a MongoDB sharded cluster handles complex queries combining embedded documents and references. The client sends a query to Mongos query routers, which route it to the correct shards based on the shard key. Replica sets on each shard retrieve embedded documents directly, while the $lookup aggregation pattern performs joins across collections to resolve references. TTL indexes run in the background to expire outdated documents automatically, ensuring data freshness without manual cleanup. Mongos then aggregates the results and returns a unified response to the client. This design balances query performance and data normalization at scale.

Primary Focus

✓

Practice

(1/5)
1. A machine learning platform needs to provide low-latency access to precomputed features for online inference at 100K requests per second. Which component is best suited to serve these feature requests efficiently?
easy
A. A relational database with complex SQL queries for feature retrieval
B. A distributed file system like HDFS storing raw feature data
C. A key-value store with in-memory caching like Redis or Memcached
D. A batch processing system like Apache Spark for on-demand feature computation

Solution

  1. Step 1: Identify low-latency requirement for online inference

    Online inference demands sub-millisecond feature retrieval, which batch systems or heavy SQL queries cannot provide efficiently.

  2. Step 2: Evaluate component suitability

    Distributed file systems and batch processing are optimized for throughput, not low latency. Relational DBs struggle with scale and latency at 100K QPS. In-memory key-value stores like Redis provide fast, scalable lookups ideal for this use case.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    In-memory key-value stores enable low-latency feature serving [check]
Hint: In-memory key-value stores excel at low-latency lookups [check]
Common Mistakes:
2. A live video streaming service requires minimal latency and can tolerate occasional packet loss. Which transport protocol is most appropriate?
easy
A. UDP, because it provides low latency without retransmission delays
B. SCTP, because it supports multi-streaming and multi-homing
C. TCP, because it guarantees packet delivery and ordering
D. HTTP over TLS, because it ensures secure and reliable delivery

Solution

  1. Step 1: Identify latency and loss tolerance requirements

    Live video streaming prioritizes low latency and can tolerate some packet loss, so retransmission delays are undesirable.

  2. Step 2: Match protocol characteristics

    UDP provides minimal overhead and no retransmission, fitting low latency needs. TCP guarantees delivery but adds delay due to retransmissions and congestion control.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    UDP suits low-latency, lossy streaming [check]
Hint: UDP trades reliability for speed in latency-sensitive apps [check]
Common Mistakes:
3. A system must handle 1 million writes per second and fan-out to millions of users asynchronously. Which component best handles decoupling write load from delivery?
easy
A. Use direct HTTP calls from sender to all receivers to guarantee delivery order
B. Use a relational database with sharded writes to handle all writes and fan-out synchronously
C. Use an in-memory cache like Redis to store all messages and fan-out immediately
D. Use a distributed message queue like Kafka to buffer writes and enable asynchronous fan-out

Solution

  1. Step 1: Identify the need for decoupling writes from fan-out

    Handling 1 million writes per second with synchronous fan-out is not feasible on a single machine or direct calls.

  2. Step 2: Evaluate components for asynchronous buffering

    Kafka provides durable, partitioned logs that buffer writes and allow scalable asynchronous delivery. Relational DBs can't handle this write load synchronously. Redis lacks durability guarantees for this scale. Direct HTTP calls block and don't scale.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Kafka buffers writes asynchronously, enabling high write throughput [check]
Hint: Use durable queues to decouple high write load [check]
Common Mistakes:
4. If the Bloom filter's hash functions are not independent and produce correlated outputs, what is the exact failure mode observed?
medium
A. The bit array will saturate quickly causing excessive false positives and reduced filter effectiveness
B. The filter will have false negatives, incorrectly rejecting existing members
C. The false positive rate increases beyond the expected theoretical rate
D. Insertions will fail silently without updating the bit array

Solution

  1. Step 1: Understand hash function independence role

    Independent hash functions distribute bits uniformly; correlated hashes cause clustering.

  2. Step 2: Trace effect of correlated hashes

    Correlated hashes set overlapping bits, saturating the bit array faster, increasing false positives and reducing filter effectiveness.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Correlated hashes cause bit array saturation, raising false positives [check]
Hint: Correlated hashes cause bit array saturation and false positives [check]
Common Mistakes:
5. If the Kafka cluster responsible for vote event streaming goes down, what exactly breaks in the Reddit voting system?
medium
A. Vote events cannot be buffered, causing vote submission requests to block or fail immediately
B. The UI shows stale post scores but votes are queued in Redis for later processing
C. Votes continue to be processed but ranking updates become inconsistent
D. Users can still vote, but votes are lost silently without any retry

Solution

  1. Step 1: Understand Kafka's role in buffering vote events

    Kafka buffers vote events reliably; if it fails, vote events cannot be streamed to processors.

  2. Step 2: Analyze failure impact

    Vote submissions do not block immediately (Vote events cannot be buffered, causing vote submission requests to block or fail immediately wrong) because frontends can still accept votes and cache temporarily. Votes are not lost silently (Users can still vote, but votes are lost silently without any retry wrong) because Redis or other caches buffer them. UI shows stale scores due to lack of processed updates (The UI shows stale post scores but votes are queued in Redis for later processing correct). Votes continue to be processed but ranking updates become inconsistent is incorrect as votes stop flowing, not just ranking inconsistency.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka failure causes stale UI scores; votes buffered in Redis [check]
Hint: Kafka down -> stale UI, votes buffered temporarily [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard