Back to roadmap
Module 2 · Scale, Latency, CapacityDay 01625 min

Workload Patterns

Read-heavy, write-heavy, fan-out, fan-in — each picks a different stack.

← PreviousNext →
Day 016

Workload Patterns

Read-heavy
note
Write-heavy
note
Fan-out
note
Fan-in
note
Memory hook

Workload Patterns: read-heavy, write-heavy, fan-out, fan-in

Mental model

make the invisible limits visible

Design lens

Redis ZSET gives O(log N) updates and O(N) reads.

Recall anchors
Read-heavyWrite-heavyFan-out

Why it matters

Different workloads call for different architectures. Read-heavy systems (e.g., feeds) want caches and replicas. Write-heavy (e.g., metrics) want logs and append stores. Fan-out (notifications, pub-sub) wants brokers. Fan-in (analytics) wants batching and stream processing.

Deep dive

Read-heavy: read replicas, caches, denormalized views.

Write-heavy: append-only logs, sharding, write-optimized stores (LSM-tree).

Fan-out: 1 input → N outputs; queues, brokers, pub-sub.

Fan-in: N inputs → 1 aggregate; stream processors, time-windowed reducers.

Demo / scenario

Real-time leaderboard.

  1. Writes: ~1000/sec score updates per game.
  2. Reads: 100k/sec viewers polling.
  3. Pattern: write-moderate, read-very-heavy + fan-out.
  4. Stack: Redis sorted set + WebSocket fan-out.

Tradeoffs

  • Redis ZSET gives O(log N) updates and O(N) reads.
  • WebSocket fan-out cuts polling cost 100×.
  • Eventual consistency between writes and broadcast (~50ms).

Diagram

Read-heavy
Write-heavy
Fan-out
Fan-in
Four workload patterns.

Mind map

Check yourself

Loading quiz…

Sources & further reading

← PreviousNext →