Skip to content

00. Event-Driven and Distributed Systems — The Five-Year-Old Version

When buildings need to coordinate without phone calls, they use a town bulletin board.

Imagine a town where every building works independently. The bakery bakes. The grocery sells. The school teaches. They don't call each other.

But sometimes they need to coordinate. The bakery runs out of flour. The grocery gets a new shipment of milk. The school needs 200 lunches tomorrow. How do they share this news without constantly phoning each other?

They use a bulletin board in the town square. The bakery posts a notice: "Need 50 kg flour by tomorrow." The grocery posts: "Fresh milk arrived." The school posts: "200 lunches needed Friday." Anyone who cares reads the board. Anyone who doesn't, ignores it.

The bulletin board is the message broker — Kafka, RabbitMQ, SQS. Producers post notices. Consumers read them. Nobody needs to know who's on the other end.

But what if two people try to update the same notice at the same time? What if the board gets full? What if someone tears off a notice before others read it? You need board rules — ordering, retention, acknowledgment. These are the guarantees that make distributed coordination reliable.

Some notices are important. "Town meeting at 5 PM." Everyone must agree on the time. If half the town thinks it's 5 PM and half thinks it's 6 PM, chaos. You need a town crier — one authoritative voice that announces the decision and makes sure everyone hears the same thing. That is consensus.

Some tasks are too big for one building. The school needs 200 lunches. The bakery makes bread, the deli makes sandwiches, the fruit stand packs apples. They work in parallel, each doing their part. But if the deli fails, do you serve 200 breadless lunches? Or do you roll everything back? That is the distributed transaction problem.

Finally, someone needs to keep track of who's open, who's closed, and where to find them. The town directory lists every building, its address, and its hours. When a new shop opens, it registers. When one closes, it deregisters. Services check the directory to find each other. That is service discovery.

Event-driven architecture is building a town that coordinates through bulletin boards instead of phone calls. Distributed systems engineering is making sure the town works even when buildings catch fire, notices get lost, and nobody can agree on the time.

The placeholders you will see called back

Placeholder Meaning
bulletin board message broker — Kafka, RabbitMQ, SQS — where events are posted and consumed
board rules delivery guarantees — ordering, at-least-once, exactly-once, retention
town crier consensus protocol — Raft, Paxos, ZooKeeper — the single source of truth
town directory service discovery — Consul, etcd, DNS — how services find each other
notice an event or message — the unit of communication between services

Top resources

What's coming

  1. 01-events-vs-commands.md — the fundamental difference between "this happened" and "do this"
  2. 02-queues-vs-streams.md — point-to-point vs publish-subscribe and when each wins
  3. 03-kafka-deep-dive.md — partitions, consumer groups, offsets, and exactly-once processing
  4. 04-sqs-rabbitmq-pubsub.md — managed queues, AMQP, and cloud-native messaging
  5. 05-retries-dlq-idempotency.md — handling failure in async systems without data loss
  6. 06-event-sourcing-and-replay.md — events as the source of truth and time-travel debugging
  7. 07-saga-pattern.md — distributed transactions without two-phase commit
  8. 08-cqrs-in-practice.md — separate read and write models powered by events
  9. 09-consistent-hashing.md — distributing data across nodes without reshuffling everything
  10. 10-consensus-raft-paxos.md — how distributed nodes agree on a single value
  11. 11-leader-election.md — choosing one boss among equals and handling failover
  12. 12-service-discovery.md — how services find each other in a dynamic environment
  13. 13-circuit-breaker-bulkhead.md — resilience patterns for distributed communication
  14. 14-honest-admission.md — what we don't fully understand about distributed systems

Bridge. Before posting anything on the bulletin board, we need to understand: is this a command or an event? The distinction changes everything. → 01-events-vs-commands.md