Module Review: Real-Time Systems

[!IMPORTANT] In this module review, you will reinforce:

  1. Key Architectural Trade-offs: Reviewing latency, state management, and consistency.
  2. Real-Time Components: Understanding when to use WebSockets, Redis, and Pub/Sub.
  3. High Concurrency Techniques: Handling thundering herds, overselling, and C10M.

1. Key Concepts Summary

In this module, we explored how to build systems that react instantly to user actions.

  • Latency is the Enemy: For “Real-Time”, we often trade Strong Consistency for Availability and Low Latency (AP systems).
  • Stateful vs Stateless: WebSockets introduce stateful connections, making scaling harder (Need Sticky Sessions or Pub/Sub Backplanes).
  • Concurrency: Handling millions of concurrent writes (Likes, Sales) requires moving locks out of the Database and into Memory (Redis).

2. Quick Reference Cheat Sheet

Problem Solution Trade-off
Counting at Scale Sharded Counters (Redis) Harder to get “Exact” count instantly.
Real-Time Feed WebSockets (2-way) or SSE (1-way) Stateful servers require intricate load balancing.
Leaderboard Redis Sorted Sets (Skiplists) RAM usage grows with user count.
Flash Sale Redis Atomic Counters (Lua) If Redis crashes without AOF, stock count is lost.
Chat Fanout Gateway Aggregation + Pub/Sub Complexity in managing subscriptions.
Thundering Herd Jitter (Random Backoff) Slightly slower recovery time.
Overselling Lua Scripting (Atomic Check-and-Set) Complex to debug Lua scripts.
Hot Partition Virtual Buckets / Consistent Hashing Resharding is complex.
Group Messaging Pub-Sub + Message Sequencers High delivery latency for huge groups.
C10M Problem Kernel Tuning / Ephemeral Ports Requires deep OS knowledge.
Approximate Counting HyperLogLog (Probabilistic) ~0.81% error rate.

3. Flashcards

Test your knowledge by clicking the cards to flip them.

Wait! How do we scale WebSockets?

(Click to reveal)

Use Redis Pub/Sub! When Server A receives a message for User B (on Server C), it publishes to a channel that Server C is listening to.

Why Redis ZSET for Leaderboards?

(Click to reveal)

Because it uses a Skiplist, allowing O(log N) inserts and O(log N) rank retrieval. SQL sorting is O(N log N) or worse on inserts.

Pessimistic vs Optimistic Locking?

(Click to reveal)

Pessimistic (SELECT FOR UPDATE) blocks others. Optimistic (Version check) allows others but fails on commit. Optimistic is better for low contention; Redis is better for high contention.

Long Polling vs SSE?

(Click to reveal)

Long Polling is a "Hack" (Request...Wait...Response). SSE is a standard "Stream" (Request...Data...Data...). SSE is cleaner but unidirectional.

How to handle "Approximate" Counts?

(Click to reveal)

Use HyperLogLog! It estimates cardinality with ~0.81% error using only ~12KB memory, saving massive amounts of RAM compared to Hash Sets.

What is a "Thundering Herd"?

(Click to reveal)

When a large number of processes/users wake up simultaneously (e.g., after a crash) and attack the server. Solution: Add random Jitter to reconnect logic.

What is the "Funnel Architecture"?

(Click to reveal)

A strategy to filter traffic at edge/cache layers before it hits the DB. CDN blocks bots → Rate Limiter drops excess → Redis Atomic handles inventory → SQL stores order.

Why use Lua Scripts in Redis?

(Click to reveal)

To ensure Atomicity. Redis runs the entire script as a single blocking operation, preventing race conditions (like checking stock and decrementing it separately).

What is the C10M Problem?

(Click to reveal)

Handling 10 Million concurrent connections. Requires bypassing standard Kernel bottlenecks (using techniques like Kernel Bypass, or extreme tuning of File Descriptors and Ephemeral Ports).

What is a CRDT?

(Click to reveal)

Conflict-Free Replicated Data Type. A data structure (like G-Counter) that can be updated independently on multiple replicas and always merges to a correct, consistent state.

Why is Redis Single-Threaded?

(Click to reveal)

To avoid context switching and locking overhead. It processes commands sequentially in an Event Loop, which is extremely fast for in-memory operations (nanoseconds).

Skiplist vs B-Tree for Leaderboards?

(Click to reveal)

Skiplists are simpler to implement (probabilistic balancing) and easier to make lock-free/concurrent compared to complex rebalancing logic in B-Trees. Redis chose Skiplists for ZSETs.

What are Sticky Sessions?

(Click to reveal)

A Load Balancer feature that routes all requests from a specific user (cookie/IP) to the SAME server. Critical for WebSockets where the connection state is local to one server.

Why Gateway Aggregation?

(Click to reveal)

To prevent Redis Pub/Sub explosion. Instead of 1 User subscribing to 100 channels, the Gateway subscribes ONCE per channel and multiplexes messages to all local users.

4. Final Assessment

If you can explain how to prevent overselling 100 iPhones to 1 Million users without crashing the DB, you are ready for the interview!

5. Next Steps

You’ve mastered Real-Time Systems and high concurrency! Next, we dive into uniquely constrained architectures that require domain-specific data structures.