Bird
Raised Fist0

Design Slack - Workspaces, Channels, Real-Time Delivery at Scale, Search

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

Receives message from Alice's client

Accepts WebSocket message and validates user and channel

Protocol:WebSocket
BeforeAlice's client has composed a plaintext message ready to send
AfterMessage accepted and forwarded to Kafka ingestion topic
Message Ingestion (Kafka)

Queues message for processing

Appends message to Kafka partition keyed by channel ID

Protocol:Kafka
BeforeMessage is received from API Gateway but not durably stored
AfterMessage durably committed to Kafka with ordering per channel
Message Storage (Cassandra)

Persists message for long-term storage

Writes message to Cassandra with channel and timestamp keys

Protocol:Cassandra CQL
BeforeMessage is durably stored in Kafka but not yet in DB
AfterMessage persisted in Cassandra for history and replay
Search Index (Elasticsearch)

Indexes message content for search

Sends message text and metadata to Elasticsearch index

Protocol:Elasticsearch REST
BeforeMessage stored in Cassandra but not searchable
AfterMessage indexed and available for full-text search queries
Presence Service (Redis)

Checks recipient Bob's online status

Queries Redis for Bob's presence key

Protocol:Redis GET
BeforeDelivery Service preparing to deliver message
AfterDelivery Service knows Bob is online and ready to receive
Delivery Service

Delivers message to Bob's client

Pushes message over WebSocket connection to Bob

Protocol:WebSocket
BeforeMessage stored and Bob's presence confirmed online
AfterBob's client receives message with delivery confirmation
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  API Gateway  │
└───────┬───────┘
        │ WebSocket
        ▼
┌───────────────────────┐
│  Message Ingestion     │
│      (Kafka)          │
└───────┬───────────────┘
        │ Kafka
        ▼
┌─────────────────────────┐
│  Message Storage        │
│  (Cassandra)            │
└───────┬─────────────────┘
        │ Cassandra CQL
        ▼
┌─────────────────────────────┐
│  Search Index                │
│  (Elasticsearch)             │
└─────────────────────────────┘
        ▲
        │ Elasticsearch REST
        │
        │
┌───────────────┐              
│ Delivery      │              
│ Service       │              
└───────┬───────┘              
        │ WebSocket             
        ▼                      
┌─────────────────────┐        
│ Presence Service     │        
│ (Redis)             │        
└─────────────────────┘
Design Rationale

This architecture shows a vertical flow from client to storage and back for delivery. The API Gateway handles WebSocket connections, forwarding messages to Kafka for durable ingestion. Kafka ensures ordered, partitioned message streams per channel. Messages are then persisted in Cassandra for long-term storage and asynchronously indexed in Elasticsearch for search capabilities. The Delivery Service consults the Presence Service (Redis) to check if recipients are online before pushing messages via WebSocket. This design balances durability, scalability, and real-time delivery by separating ingestion, storage, indexing, presence, and delivery into specialized components.

Primary Focus

✓

Practice

(1/5)
1. In a system trace, at Step 3 the Storage Estimator component calculates daily storage needs. If the average object size is 2MB and the system expects 500K new objects daily, what is the storage estimate at Step 3?
easy
A. Cannot estimate without knowing retention period
B. 1TB per day, calculated as 500K objects x 2MB each
C. 2TB per day, assuming 4MB average object size instead
D. 500GB per day, assuming 1MB average object size instead

Solution

  1. Step 1: Calculate daily storage

    Multiply 500,000 objects by 2MB each = 1,000,000 MB = 1TB per day.

  2. Step 2: Eliminate other options

    500GB per day, assuming 1MB average object size instead uses wrong object size; 2TB per day, assuming 4MB average object size instead doubles size incorrectly; Cannot estimate without knowing retention period ignores that retention affects total storage, not daily estimate.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    500K x 2MB = 1TB daily storage [check]
Hint: Daily storage = object count x average size [check]
Common Mistakes:
2. Without a durable message queue like Kafka, what exactly breaks in a chat system's message delivery?
medium
A. The system fails to authenticate users leading to unauthorized access
B. Messages are encrypted incorrectly causing security breaches
C. Messages are duplicated multiple times due to lack of deduplication
D. Alice's send blocks until Bob responds; if Bob's server crashes, message is lost with no retry

Solution

  1. Step 1: Identify role of durable queue

    Kafka decouples sender and receiver; without it, sender waits synchronously for receiver's ack.

  2. Step 2: Trace failure without Kafka

    If Bob's server crashes, no ack arrives, send blocks indefinitely and message is lost with no retry mechanism.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    No Kafka -> synchronous send blocks, message lost if receiver crashes [check]
Hint: No Kafka -> send blocks and message lost if receiver crashes [check]
Common Mistakes:
3. For a distributed key-value store that must handle frequent node additions and removals with minimal key remapping, which approach is best?
medium
A. Use modular hashing with a fixed bucket count and rehash keys on node changes
B. Use a centralized directory service mapping keys to nodes updated on every node change
C. Use consistent hashing with virtual nodes to balance load and minimize remapping
D. Use rendezvous hashing to assign keys to nodes without a ring structure

Solution

  1. Step 1: Compare modular hashing and consistent hashing

    Modular hashing requires full remapping on node changes, causing high overhead.

  2. Step 2: Evaluate alternatives

    Centralized directory adds latency and single point of failure; rendezvous hashing is good but less common and more complex than consistent hashing with virtual nodes.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Consistent hashing with virtual nodes balances load and minimizes remapping [check]
Hint: Virtual nodes smooth load, minimize remap on node changes [check]
Common Mistakes:
4. If Zookeeper's session timeout mechanism fails to detect a crashed leader node promptly, what is the most likely failure observed in the leader election process?
medium
A. Multiple nodes simultaneously assume leadership causing split-brain
B. Leader election proceeds normally due to backup leader election mechanism
C. Followers wait indefinitely for leader node removal, blocking leader election
D. Clients receive stale configuration but leader election continues

Solution

  1. Step 1: Understand session timeout role

    Session timeout detects leader failure by ephemeral node removal.

  2. Step 2: Failure of timeout detection

    If timeout fails, ephemeral node remains, so followers do not start election; no split-brain occurs.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Backup election mechanisms prevent split-brain despite timeout failure [check]
Hint: Session timeout failure -> ephemeral node stays -> no immediate election [check]
Common Mistakes:
5. At 10x scale, which component in a real-time chat system implementing CAP theorem fails first and why?
hard
A. The database fails first due to increased write amplification
B. The message queue fails first due to partition key hotspots causing uneven load
C. Chat servers fail first because WebSocket connections are stateful and cannot be resharded easily
D. The load balancer fails first due to inability to handle increased connection churn

Solution

  1. Step 1: Identify stateful bottleneck

    Chat servers maintain WebSocket connections statefully, limiting horizontal scaling.

  2. Step 2: Understand scaling impact

    At 10x scale, existing WebSocket connections cannot be moved, causing chat servers to saturate first.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful WebSocket servers bottleneck scaling before DB or load balancer [check]
Hint: Stateful WebSocket servers bottleneck scaling first [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