Intermediate Track · Modules 21–46
26 modules.
The distributed arc.
The Beginner track gave you one machine and the vocabulary to scale it. This track hands you the real thing: distributed state, event-driven architecture, microservices, stream processing — and two capstone designs that put it all together. Start at Module 21 and work forward.
New to system design? Start with the Beginner track →
Phase E — Distributed Reality · Modules 21–25
M.21
→
M.22
→
M.23
→
M.24
→
M.25
→
CAP Theorem
The moment a system runs on two machines, an unfixable trade-off appears. CAP stated correctly (not the usual myth), the real CP vs AP production choice, and PACELC — the trade-off CAP doesn't tell you about.
Consistency Models
"Eventually consistent" is actually six different promises. Linearizable, sequential, causal, read-your-writes, monotonic, eventual — the precise spectrum, and where your database actually sits on it.
Time, Order & Clocks
Distributed systems have no shared clock. Lamport's 1978 insight — stop measuring time, measure causality. Logical clocks, vector clocks, and what each can and cannot tell you about "what happened first."
Consensus & Raft
Five nodes, one total order, failures everywhere. Leader election, log replication, quorum majorities — how Raft keeps a cluster telling one story while the network lies.
Replication Patterns
Single-leader, multi-leader, leaderless — the three canonical shapes of replication, their failure modes, and how to match each to the workload in front of you. Phase E finale.
Phase F — Event-Driven at Scale · Modules 26–31
M.26
→
M.27
→
M.28
→
M.29
→
M.30
→
M.31
→
Message Brokers
Synchronous calls are fine until the third service down the chain is on fire. Kafka vs RabbitMQ, partitions, consumer groups, offsets, acknowledgements — the machinery of handing off work across failures and time.
Pub/Sub Patterns
A broker is just a wire. Direct, fanout, topic-pattern, work queue, dead-letter — the five routing patterns that turn "we have Kafka" into a working event-driven architecture.
Event Sourcing
Stop storing current state — store the events that produced it. Append-only logs, projections, snapshots, and replay: the pattern behind every banking ledger and audit trail worth its name.
CQRS
Reads and writes have different shapes; one model serving both is a compromise neither side wins. Splitting the two — how it works, when it pays off, and what it costs in eventual consistency.
Sagas & Distributed Transactions
Five services, no shared database, any of them can fail. Choreography vs orchestration, compensating actions — and why "rollback" across services is really apologizing in business terms.
Exactly-Once & Idempotency
Impossible in theory (Two Generals, 1975), achievable in practice: at-least-once delivery + idempotent consumers + the transactional outbox. The stack holding up every delivery guarantee. Phase F finale.
Phase G — Microservices in Practice · Modules 32–38
M.32
→
M.33
→
M.34
→
M.35
→
M.36
→
M.37
→
M.38
→
Service Boundaries & DDD
The harder question behind microservices: what should even be a service? Bounded contexts, ubiquitous language, aggregates, and context maps — the DDD vocabulary for drawing lines that hold.
API Gateways
Your client now has to talk to five services instead of one. Routing, auth offload, rate limiting, request aggregation, BFFs — and how to stop the gateway becoming what it was meant to prevent.
Service Mesh
East-west traffic: every internal call needs mTLS, retries, circuit breaking, tracing. The sidecar pattern that provides all of it without touching application code.
Service Discovery
Pods come up, pods go down, IPs get recycled. Client-side vs server-side discovery, health checks, and the registries — Consul, etcd, Kubernetes DNS — that keep a changing fleet addressable.
Distributed Tracing
The request touched fifteen services and one of them took four seconds — which one? Trace IDs, spans, context propagation, and the sampling strategies that make tracing affordable at scale.
Polyglot Persistence
One database serves every workload adequately and none optimally. Matching each bounded context to the store its work actually needs — and the real price of running six databases instead of one.
Inter-Service Communication
Sync REST, async events, choreography, orchestration — the decision framework that determines whether you built a graceful microservices architecture or a distributed monolith in disguise. Phase G finale.
Phase H — Streams & Data Pipelines · Modules 39–43
M.39
→
M.40
→
M.41
→
M.42
→
M.43
→
Batch vs Stream
The foundational data-processing decision. Bounded chunks after the fact vs continuous processing as data arrives — different latency, throughput, consistency, and operational shapes.
Windowing
An unbounded stream has no "last hour" — you have to define it. Tumbling, sliding, and session windows; event time vs processing time; watermarks and allowed lateness.
Stateful Stream Processing
Every non-trivial stream operator remembers something, and a 3 AM crash puts all of it at stake. Keyed state, checkpoints, state backends, savepoints — how the state survives.
Change Data Capture
Your streams have to come from somewhere — usually an operational database that was never designed to be streamed. Log-based CDC: reading the WAL, binlog, and oplog directly, Debezium-style.
Real-Time Analytics
The last hop: streams become queryable. Streaming SQL (Materialize, RisingWave) vs real-time OLAP (Pinot, Druid, ClickHouse) — and when each family wins. Phase H finale.
Phase I — Capstones & Finale · Modules 44–46
M.44
→
M.45
→
M.46
→
Build: Distributed K-V Store
The canonical capstone. Consistent hashing, replication topologies, quorums, hinted handoff, anti-entropy — every Phase E concept composed into one coherent design.
Build: Real-Time Analytics Platform
The composition capstone. CDC, stream processing, windowing, and OLAP serving assembled into one platform — designed three times at three different scales.
Interview Toolkit
46 modules compressed into a working interview framework: the four-phase structure, eight system archetypes, capacity math, and the signals interviewers score at L4, L5, and L6. Track finale.
What's next
The Expert track.
27 more modules. Consensus internals, storage and query engines, hardware-aware design, formal verification, ML systems — then observability, chaos, multi-tenancy, DR, FinOps, platform engineering and privacy. The material that separates senior from staff engineering.
Enter the Expert track →