Bird
Raised Fist0

Scalability - Designing for 10x, 100x, 1000x Traffic Growth from Day One

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

Receives client request

API Gateway accepts incoming WebSocket request and validates it

Protocol:WebSocket
BeforeClient request is pending on the network
AfterRequest accepted and ready to be published to Kafka
Kafka Cluster

Queues request message

API Gateway publishes request message to Kafka topic partition

Protocol:Kafka Publish
BeforeRequest message is in API Gateway memory
AfterMessage durably stored in Kafka partition for processing
Processing Workers

Consumes message and processes request

Worker reads message from Kafka, performs business logic

Protocol:Kafka Consume
BeforeMessage is available in Kafka partition
AfterMessage processed, results ready to update cache and DB
Redis Cache

Updates cache with processed data

Worker writes processed data to Redis for fast future reads

Protocol:Redis SET
BeforeCache does not have latest processed data
AfterCache updated with fresh data for low-latency access
Cassandra DB

Persists processed data

Worker writes processed data to Cassandra for durable storage

Protocol:Cassandra Write
BeforeProcessed data only in cache and worker memory
AfterData durably stored in Cassandra for fault tolerance
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ WebSocket
        ▼
┌───────────────┐
│ Kafka Cluster │
└───────┬───────┘
        │ Kafka Pub
        ▼
┌───────────────────┐
│ Processing Workers │
└───────┬───────────┘
        │ Redis SET/GET
        ▼
┌─────────────┐
│ Redis Cache │
└───────┬─────┘
        │ Cassandra Write
        ▼
┌─────────────┐
│ CassandraDB │
└─────────────┘
Design Rationale

This architecture is designed for massive scalability by decoupling components with Kafka, allowing asynchronous processing. The API Gateway handles client connections and forwards requests to Kafka, which buffers traffic spikes. Processing Workers consume Kafka messages to perform business logic, then update Redis Cache for fast reads and Cassandra DB for durable storage. Redis reduces load on Cassandra by caching hot data, improving latency under heavy traffic. Cassandra's distributed design supports horizontal scaling for persistent data. This vertical flow ensures each component can scale independently, enabling the system to handle 10x to 1000x traffic growth without bottlenecks.

Primary Focus

✓

Practice

(1/5)
1. In a chat system, at step 4 the Delivery Worker checks Bob's presence TTL in Redis before delivering a message. What happens if Bob's presence key has expired at this step?
easy
A. The Delivery Worker delivers the message immediately to Bob's device
B. The Delivery Worker queues the message for offline delivery and marks it as undelivered
C. The Delivery Worker deletes the message assuming Bob is offline permanently
D. The Delivery Worker retries checking Bob's presence key indefinitely

Solution

  1. Step 1: Trace Delivery Worker decision at Step 4 -- Bob's presence TTL

    If Bob's presence key expired, it means Bob is offline. The worker should queue the message for offline delivery and mark it undelivered.

  2. Step 2: Eliminate wrong states

    Delivering immediately (The Delivery Worker delivers the message immediately to Bob's device) ignores offline status. Deleting message (The Delivery Worker deletes the message assuming Bob is offline permanently) causes data loss. Retrying indefinitely (The Delivery Worker retries checking Bob's presence key indefinitely) blocks delivery pipeline.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Expired presence -> queue for offline delivery [check]
Hint: Expired presence means offline; queue message for later [check]
Common Mistakes:
2. In a system where Step 4 is the Delivery Worker checking message delivery status, what happens if the Delivery Worker finds the recipient's presence TTL expired?
easy
A. The Delivery Worker queues the message for offline delivery and updates status to 'sent but not delivered'
B. The Delivery Worker immediately marks the message as delivered without retry
C. The Delivery Worker deletes the message assuming recipient is unreachable
D. The Delivery Worker retries sending indefinitely until TTL is refreshed

Solution

  1. Step 1: Trace Delivery Worker decision at Step 4 -- Bob's presence TTL

    If TTL expired, recipient is offline; message can't be delivered immediately.

  2. Step 2: Understand offline delivery handling

    Delivery Worker queues message for later delivery and marks status as 'sent but not delivered' to reflect state.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Expired TTL -> queue message, status 'sent but not delivered' [check]
Hint: Expired TTL means offline, queue message for later delivery [check]
Common Mistakes:
3. If the commit metadata database becomes unavailable, what is the immediate failure observed when a user tries to create a new branch?
medium
A. The system creates the branch but marks it as unverified until metadata is restored
B. The branch creation request fails immediately with an error indicating metadata service unavailability
C. The system queues the branch creation request and retries later without user notification
D. The branch is created locally on the client but not persisted to the server

Solution

  1. Step 1: Understand role of commit metadata DB

    Commit metadata DB stores branch pointers; without it, server cannot persist new branches.

  2. Step 2: Trace branch creation failure

    Client may create branch locally, but server cannot persist it, so branch is effectively lost or inconsistent.

  3. Step 3: Eliminate other options

    Queuing without notification hides failure; immediate error is possible but not typical if client allows local ops; marking unverified branches requires metadata DB access.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Metadata DB down -> branch created locally but not persisted [check]
Hint: Metadata DB down -> local branch only, no server persistence [check]
Common Mistakes:
4. A team must decide between using a detailed blame-focused report or a blameless timeline with action items for their post-mortem. Which approach is best for fostering continuous improvement in a high-trust engineering culture?
medium
A. Use blameless timelines with actionable steps to encourage learning and improvement
B. Use blame-focused reports to enforce accountability and prevent future errors
C. Use only automated logs without human analysis to avoid bias
D. Skip post-mortems entirely to save time and avoid conflict

Solution

  1. Step 1: Evaluate cultural impact of blame vs blameless approaches

    Blame-focused reports create fear and reduce openness, harming continuous improvement.

  2. Step 2: Assess effectiveness of blameless timelines with action items

    They foster trust, encourage learning, and drive actionable improvements aligned with high-trust culture.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Blameless + action items -> continuous improvement [check]
Hint: Blameless + action items build trust and improve systems [check]
Common Mistakes:
5. At 10x scale, which component of the Snowflake ID generation system is most likely to become the bottleneck first, and why?
hard
A. The timestamp source, because clock synchronization across machines becomes impossible at scale.
B. The network bandwidth, because ID generation requires frequent coordination between machines.
C. The sequence number, because generating more than its max IDs per millisecond causes blocking delays.
D. The machine ID allocation, because limited machine ID bits cause ID collisions as machines increase.

Solution

  1. Step 1: Analyze timestamp and network constraints

    Timestamp synchronization (A) is challenging but tolerable with NTP; network coordination (D) is minimal as IDs are generated locally.

  2. Step 2: Evaluate sequence number limits

    Sequence number (B) limits per millisecond can cause blocking but can be mitigated by load balancing or sharding.

  3. Step 3: Identify machine ID allocation bottleneck

    Machine ID bits are fixed (e.g., 10 bits), limiting the number of unique machines. At 10x scale, running out of unique machine IDs causes collisions or requires complex reallocation.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Fixed machine ID bits limit scale -> collisions or reconfiguration needed [check]
Hint: Fixed machine ID bits limit scale before sequence or timestamp issues [OK]
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