Event-Driven Architecture

An architectural style where components communicate by producing and consuming events, which are immutable facts about something that happened ('OrderPlaced', 'PaymentCaptured'). Producers emit events to a broker without knowing who consumes them; consumers subscribe and react. Contrast with request-driven architecture, where a service explicitly calls the services it depends on.

Direct request-driven calls tightly couple services: the caller must know every downstream, and adding a new reaction means changing the caller. Event-driven architecture inverts this: the producer announces a fact and stays ignorant of consumers. You can add new consumers (analytics, notifications, fraud) without touching the producer, absorb spikes through the broker, and let each consumer fail and recover independently.

A producer publishes an event to a broker (Kafka topic, message queue, event bus). Subscribers consume it asynchronously and react, often emitting their own events, forming a choreography. Two flavors: event notification (thin event, consumer fetches details if needed) and event-carried state transfer (event carries the full payload so consumers need no callback). The broker provides durability, replay, and buffering. Because everything is async, the system is eventually consistent rather than immediately consistent.

• Extreme loose coupling, since producers don't know or care who consumes their events
• Add new consumers (analytics, notifications, audit) without touching producers
• The broker buffers spikes and lets each consumer scale, fail, and recover independently

• Eventual consistency by default: there's no single moment the whole system agrees on state
• Hard to reason about and debug: the end-to-end flow is implicit, spread across many async reactions
• At-least-once delivery means consumers must be idempotent, and event ordering across topics is not guaranteed

• Apache Kafka →

  The event backbone, where producers publish domain events to topics that any number of independent consumer groups react to

• Notification System →

  Other systems emit events ('order shipped'); the notification service reacts and fans out, with no caller coupling

• Bluesky (AT Protocol) →

  The global firehose Relay is an event stream; AppViews and custom feeds are consumers that react to the event log independently

• Eventual consistency is the default, not a bug, but it surprises people. There's no instant after which the whole system is in sync; design UIs and flows to tolerate the lag.
• Debugging is genuinely harder: no stack trace spans the flow. You need distributed tracing with event/correlation IDs propagated through every event, or incidents become archaeology.
• Consumers must be idempotent (at-least-once delivery) and tolerant of out-of-order events across topics. Don't assume global ordering; partition by key where order matters.
• Events are immutable facts in the past tense ('OrderPlaced'), not commands ('PlaceOrder'). Modeling them as commands re-couples producer and consumer and defeats the point.