Bird
Raised Fist0

Stateless vs Stateful Services - Design Implications at Scale

HLDmediumInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/7
Load Balancer

Receives client HTTP request and routes it

Load Balancer forwards request to a stateless service instance

Protocol:HTTP/REST
BeforeClient request arrives at Load Balancer
AfterRequest forwarded to Stateless Service instance
Stateless Service

Processes request and produces event message

Stateless Service does not store session, sends event to Kafka

Protocol:Kafka Produce
BeforeStateless Service has no client session state
AfterEvent message durably stored in Kafka Cluster
Kafka Cluster

Queues event message for consumption

Kafka partitions ensure ordering per client session

Protocol:Kafka Consume
BeforeEvent message stored in Kafka topic partition
AfterStateful Service consumes event message
Stateful Service

Processes event and updates session state in Redis

Stateful Service reads/writes session data in Redis Cache

Protocol:Redis GET/SET
BeforeSession state cached in Redis for client
AfterSession state updated with new event data
Redis Cache

Serves session state requests and falls back to DB if needed

If cache miss, Redis queries Cassandra for durable state

Protocol:CQL Query
BeforeSession state partially cached in Redis
AfterSession state refreshed from Cassandra if cache miss
Cassandra Cluster

Stores durable session state and event history

Cassandra replicates data for fault tolerance

Protocol:CQL Query
BeforeDurable session state stored in Cassandra
AfterDurable session state replicated across Cassandra nodes
Zookeeper Cluster

Manages distributed coordination and leader election

Ensures consistency and availability of stateful services

Protocol:Internal Coordination
BeforeZookeeper cluster running with quorum
AfterStateful Service cluster remains consistent and available
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│ Load Balancer │
└───────┬───────┘
        │ HTTP/REST
        ▼
┌───────────────────┐
│ Stateless Service  │
│ (no client state)  │
└───────┬───────────┘
        │ Kafka Produce
        ▼
┌───────────────┐
│ Kafka Cluster │
└───────┬───────┘
        │ Kafka Consume
        ▼
┌───────────────────┐
│ Stateful Service   │
│ (maintains session)│
└───────┬───────────┘
        │ Redis GET/SET
        ▼
┌───────────────┐
│ Redis Cache   │
└───────┬───────┘
        │ CQL Query
        ▼
┌───────────────────┐
│ Cassandra Cluster  │
└───────┬───────────┘
        │ Zookeeper Coordination
        ▼
┌───────────────────┐
│ Zookeeper Cluster  │
└───────────────────┘
Design Rationale

This architecture illustrates the flow of a client request through a load balancer to a stateless service, which produces an event to Kafka. Kafka decouples the stateless and stateful services, enabling asynchronous processing. The stateful service consumes events from Kafka and manages client session state using Redis cache for fast access and Cassandra for durable storage. Zookeeper coordinates distributed state and leader election to maintain consistency. This design highlights the trade-offs between stateless services that scale easily but require external state management, and stateful services that maintain session but depend on caches and databases for durability and coordination. Understanding this flow is critical for designing scalable, resilient systems that balance state management and performance.

Primary Focus

✓

Practice

(1/5)
1. In the indexing pipeline, at step 3, the Indexer receives a batch of parsed documents. What state does the Indexer maintain immediately after processing this batch?
easy
A. The Indexer updates the inverted index with new terms but keeps the batch metadata for consistency checks
B. The Indexer sends the batch to the PageRank component before updating the index
C. The Indexer marks the batch as indexed and immediately deletes the raw documents
D. The Indexer queues the batch for re-parsing if term frequency thresholds are not met

Solution

  1. Step 1: Trace Indexer behavior at step 3

    The Indexer updates the inverted index with terms from the batch and retains batch metadata for consistency and fault tolerance.

  2. Step 2: Eliminate incorrect states

    Deleting raw documents immediately risks data loss. PageRank runs after indexing, not before. Re-parsing is triggered by errors, not term frequency.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Indexer updates index and keeps metadata for consistency [check]
Hint: Indexer updates index, keeps metadata for consistency [check]
Common Mistakes:
2. In the Kafka consumer flow, at step 4 the consumer commits offsets after processing messages. What happens if the consumer crashes before committing the offset?
easy
A. The messages are reprocessed after restart, causing potential duplicates
B. The messages are lost and never reprocessed
C. Kafka automatically commits offsets on behalf of the consumer
D. The consumer group coordinator reassigns partitions immediately

Solution

  1. Step 1: Trace offset commit role at Step 4

    Offset commit marks messages as processed; if not committed, Kafka considers them unprocessed.

  2. Step 2: Understand crash impact

    If consumer crashes before commit, on restart it reprocesses messages from last committed offset, causing duplicates.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Uncommitted offsets cause message reprocessing [check]
Hint: Uncommitted offset -> message replay on restart [OK]
Common Mistakes:
3. If the WebSocket server crashes unexpectedly, what is the immediate failure mode experienced by connected clients?
medium
A. Clients automatically reconnect without losing any messages due to built-in buffering.
B. Clients switch to Long Polling automatically to maintain connection without message loss.
C. Clients receive a connection close event and must reconnect; messages sent during downtime are lost unless application-layer retries exist.
D. Clients continue to send messages which are queued by the network until the server recovers.

Solution

  1. Step 1: Understand WebSocket failure behavior

    When the WebSocket server crashes, the TCP connection closes, and clients receive a close event.

  2. Step 2: Trace message delivery impact

    Messages sent during downtime are lost unless the application implements retries. Clients must reconnect manually or via client logic. There is no automatic buffering or fallback to Long Polling.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    WebSocket crash -> connection close event, no automatic buffering [check]
Hint: WebSocket crash -> clients disconnect, no auto-retry [check]
Common Mistakes:
4. If the Bloom filter component is removed from the system, what exact failure occurs during key lookups?
medium
A. Every key lookup hits the backend, causing increased latency and possible backend saturation
B. The system returns false negatives, missing existing keys due to lack of filtering
C. Backend database rejects all queries due to overload, causing 503 errors
D. The system returns false positives, incorrectly indicating keys exist

Solution

  1. Step 1: Understand Bloom filter removal impact

    Without Bloom filters, no pre-filtering occurs, so all lookups go to backend.

  2. Step 2: Analyze failure modes

    Backend overload (A) is possible but not guaranteed. Increased latency (B) is true but not a failure mode. False positives (D) come from Bloom filters, not their absence. False negatives (C) occur if system relies on Bloom filter to avoid missing keys.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Without Bloom filter, system risks missing keys due to no probabilistic filtering [check]
Hint: No Bloom filter means missing keys, false negatives appear [check]
Common Mistakes:
5. At 10x current scale, which component in the Reddit voting and ranking system is most likely to fail first, and why?
hard
A. The relational database storing user profiles, due to increased read queries
B. The ranking service's in-memory cache, because it cannot shard scores by post_id effectively
C. The WebSocket servers maintaining live connections, because stateful connections cannot be resharded easily
D. The Kafka cluster, due to partition leader election delays under heavy load

Solution

  1. Step 1: Analyze stateful vs stateless components at scale

    Relational DB (The relational database storing user profiles, due to increased read queries) can be scaled with read replicas; Kafka (The Kafka cluster, due to partition leader election delays under heavy load) scales well with partitions. Ranking cache (The ranking service's in-memory cache, because it cannot shard scores by post_id effectively) can shard by post_id.

  2. Step 2: Identify WebSocket server bottleneck

    WebSocket servers hold stateful connections bound to server memory; these connections cannot be moved easily, limiting horizontal scaling and causing failures under 10x load.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful WebSocket servers fail first due to unshardable live connections [check]
Hint: Stateful WebSocket servers bottleneck at 10x scale [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