Bird
Raised Fist0

How to Structure Any System Design Answer in 45 Minutes

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
API Gateway Layer

Receives client write request

API Gateway accepts HTTP POST with data payload

Protocol:HTTP/REST
BeforeClient has data ready to send
AfterRequest accepted and forwarded to Write Service
Write Service(s)

Processes write request and publishes event

Write Service validates and produces event to Kafka topic

Protocol:Kafka Produce
BeforeWrite Service has received request from API Gateway
AfterEvent durably stored in Kafka cluster
Kafka Cluster

Stores event and delivers to consumers

Kafka persists event and makes it available for consumption

Protocol:Kafka Consume
BeforeEvent just produced by Write Service
AfterEvent ready for consumption by Write Service consumer
Cassandra Storage Service

Persists event data

Write Service consumer reads from Kafka and writes to Cassandra

Protocol:CQL Write
BeforeEvent available in Kafka for consumption
AfterData durably stored in Cassandra
Read Service(s)

Reads data on client query

Read Service queries Cassandra and returns data via API Gateway

Protocol:CQL Read
BeforeData stored in Cassandra, client requests read
AfterRequested data retrieved and ready to send to client
API Gateway Layer

Returns read response to client

API Gateway sends HTTP response with requested data

Protocol:HTTP/REST
BeforeRead Service has data ready to return
AfterClient receives requested data
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────────────┐
│   API Gateway Layer   │
└────────────┬──────────┘
             │ HTTP/REST
             ▼
┌───────────────────────┐
│    Write Service(s)   │
└────────────┬──────────┘
             │ Kafka Produce
             ▼
┌───────────────────────┐
│    Kafka Cluster      │
└────────────┬──────────┘
             │ Kafka Consume
             ▼
┌───────────────────────┐
│ Cassandra Storage Svc │
└────────────┬──────────┘
             │ CQL Write
             ▼
┌───────────────────────┐
│    Read Service(s)    │
└────────────┬──────────┘
             │ CQL Read
             ▼
┌───────────────────────┐
│   API Gateway Layer   │
└───────────────────────┘
Design Rationale

This architecture shows a typical event-driven system design with clear separation of write and read paths. The API Gateway handles client HTTP requests, routing writes to Write Service(s) which produce events to Kafka. Kafka acts as a durable, scalable message queue decoupling producers and consumers. Write Service consumers persist data into Cassandra Storage Service, a distributed database optimized for high write throughput. Read Service(s) query Cassandra to serve client read requests via the API Gateway. This design enables scalability, fault tolerance, and clear data flow, ensuring writes are durably stored before reads serve consistent data.

Primary Focus

✓

Practice

(1/5)
1. A distributed cache must evenly distribute keys across nodes and minimize rehashing when nodes join or leave. Which component best handles this requirement?
easy
A. Random key assignment to any available cache node
B. A simple modulo-based hash function on node count
C. Centralized directory service mapping keys to nodes
D. Consistent hashing ring with virtual nodes

Solution

  1. Step 1: Understand key distribution and node churn

    Modulo hashing fails when nodes change, causing massive remapping; centralized directory adds bottleneck.

  2. Step 2: Consistent hashing with virtual nodes

    This approach evenly distributes keys and minimizes remapping on node changes by mapping keys and nodes on a hash ring.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Consistent hashing minimizes remapping on node changes [check]
Hint: Consistent hashing minimizes remap on node changes [OK]
Common Mistakes:
2. For delivering real-time location updates to mobile clients, which approach is better considering intermittent mobile network connectivity and battery constraints?
medium
A. Use WebSocket connections with automatic reconnection and heartbeat pings
B. Use persistent gRPC streaming connections to push updates continuously
C. Use HTTP long polling to simulate real-time updates
D. Use periodic client polling every few seconds to fetch updates

Solution

  1. Step 1: Evaluate persistent connection options

    gRPC streaming is efficient but less supported on mobile platforms and can drain battery.

  2. Step 2: Compare WebSocket and polling

    WebSocket supports bidirectional communication with reconnection and heartbeats, balancing real-time and battery use better than polling.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    WebSocket balances real-time updates and mobile constraints [check]
Hint: WebSocket with reconnection beats gRPC streaming on mobile [check]
Common Mistakes:
3. For job recommendation ranking, which architecture better supports real-time updates to user preferences and job postings with low latency and high throughput?
medium
A. Batch processing of job and user data nightly with offline model training
B. Online feature store with streaming data pipelines and real-time model scoring
C. Periodic REST API calls to external recommendation services with caching
D. Manual curation of job recommendations updated weekly by content teams

Solution

  1. Step 1: Analyze latency and throughput requirements

    Real-time updates require low latency and high throughput, which batch processing (Batch processing of job and user data nightly with offline model training) and manual curation (Manual curation of job recommendations updated weekly by content teams) cannot provide.

  2. Step 2: Compare online feature store vs periodic REST calls

    Online feature store with streaming pipelines (Online feature store with streaming data pipelines and real-time model scoring) supports continuous updates and real-time scoring, unlike periodic REST calls (Periodic REST API calls to external recommendation services with caching) which add latency and stale data.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Streaming pipelines + online store -> real-time low latency [check]
Hint: Streaming pipelines enable real-time model updates [OK]
Common Mistakes:
4. At 10x current scale, which component in the YouTube view count system is most likely to fail first, and why?
hard
A. The CDN edge caches because they cannot handle the increased video delivery requests
B. The view count database because it is a centralized bottleneck for high write throughput
C. The transcoding pipeline because it cannot process 10x more video uploads in time
D. The upload service because it cannot handle 10x concurrent upload connections

Solution

  1. Step 1: Analyze component scalability at 10x load

    CDN edge caches (A) scale horizontally and are designed for massive read throughput. Transcoding pipeline (C) can be scaled with more workers. Upload service (D) can be scaled with load balancers and stateless servers.

  2. Step 2: Identify view count database bottleneck

    View count DB is a centralized write hotspot with high contention and latency sensitivity. At 10x scale, it becomes the first bottleneck due to write amplification and consistency requirements.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Centralized view count DB write bottleneck fails first [check]
Hint: Centralized DB write bottleneck breaks first at scale [check]
Common Mistakes:
5. At 10x scale, which component in a multi-tier storage system is most likely to become the bottleneck first, and why?
hard
A. Archive storage because tape drives have limited concurrent access bandwidth
B. Metadata service because it maintains global access frequency and tiering decisions, causing high coordination overhead
C. Cold storage because object storage scales linearly with data size
D. Warm storage because HDDs have slower seek times but can be scaled horizontally easily

Solution

  1. Step 1: Identify component roles at scale

    Archive storage uses tape drives with limited concurrent access bandwidth and high latency.

  2. Step 2: Analyze scaling challenges

    At 10x scale, tape drives become bottleneck due to limited parallelism and slow seek times, unlike metadata which can be sharded.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Archive tape bandwidth limits -> first bottleneck [check]
Hint: Tape archive bandwidth limits scale poorly [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