queues
Queues, Streams, Eventing
Letting parts of a system hand off work through message queues instead of waiting on each other — so things stay fast and survive a crash without losing a message.
Start track → 00
Start from zero
Before the senior material: what a message queue even is, and the handful of words the rest of the track assumes you already know. 01
Delivery guarantees: at-most-once, at-least-once, and the truth about exactly-once
Exactly-once delivery is impossible (Two Generals). At-least-once + idempotent consumer = effectively-once. Kafka transactions, SQS visibility timeout, and the outbox pattern are the production tools. 01 At-most-once, at-least-once, exactly-once: the three delivery contracts 8 min 02 The three failure legs — where duplicates and losses actually happen 10 min 03 Consumer-side dedup: the cheapest path to exactly-once processing 12 min 04 Kafka exactly-once semantics: idempotent producer and transactions 12 min 05 SQS visibility timeout, DLQ, and the outbox pattern 11 min 06 Exactly-once in production: impossibility proof, hybrid patterns, and real incidents 14 min 07 Delivery guarantees: multiple-choice review 13 min 08 Delivery guarantees: free-recall review 13 min 09 Delivery guarantees: code and log reading 14 min 10 Delivery guarantees: build a crash-proof payment consumer 240 min
02
Kafka partitions
How Kafka distributes messages across partitions, assigns consumer group members, and why partition count is a one-way door. 03
RabbitMQ exchanges and routing
Direct, fanout, topic, and headers exchanges — how binding keys route messages and where each pattern fits in production. 01 RabbitMQ exchanges: the routing layer that decides who gets a copy 16 min 02 RabbitMQ exchanges: multiple-choice review 12 min 03 RabbitMQ exchanges: free-recall review 13 min 04 RabbitMQ exchanges: config and routing reading 14 min 05 RabbitMQ exchanges: build an order-events routing fabric 240 min
04
Message ordering guarantees
Why total order is expensive, how Kafka delivers per-partition FIFO, and the practical patterns for preserving order in distributed consumers. 05
The transactional outbox pattern
Write a database row and a message atomically — how the outbox table, polling relay, and CDC eliminate the dual-write problem. 06
Change-Data Capture
Reading the database write-ahead log to stream every row change as an event — Debezium, Postgres logical replication, and the operational gotchas. 01 Change-Data Capture: streaming the write-ahead log without filling the disk 16 min 02 Change data capture: multiple-choice review 12 min 03 Change data capture: free-recall review 13 min 04 Change data capture: config and query reading 14 min 05 Change data capture: ship CDC and survive a stalled slot 240 min
07
Designing UX for eventual consistency
Optimistic UI, conflict resolution, progress indicators, and retry affordances — making asynchronous systems feel responsive to users. 01 Designing UX over async backends: optimistic UI, pending states, read-your-writes 17 min 02 Eventual-consistency UX: multiple-choice review 13 min 03 Eventual-consistency UX: free-recall review 14 min 04 Eventual-consistency UX: code reading 14 min 05 Eventual-consistency UX: make an async backend feel instant 240 min
08
Putting it together: event-driven service mesh
End-to-end design of an order-processing pipeline — outbox, Kafka topics, consumer groups, CDC, dead-letter queues, and observability.Build with this track
Guided projects that exercise what you learn here.
At-least-once job queue
Build a durable job queue on Postgres with visibility timeouts and idempotent consumers, so a crashed worker never drops a job.
Collaborative cursors
Show every connected user's live cursor and selection in a shared document, conflict-free, over WebSocket.
Job scheduler
A cron + backoff job runner with at-least-once delivery, idempotent handlers, and visibility timeouts — so no job is silently lost even when workers crash mid-execution.
Distributed Systems
What goes wrong when one system runs across many machines — and how they agree, stay available, and avoid making outages worse. Advanced; comfortable with one backend first.