How does event-driven architecture differ from request-response?

19 Eyl 14:26

Think of EDA as a “publish‑and‑forget” model: a service emits an event (e.g., OrderCreated) and immediately moves on, while a broker (Kafka, RabbitMQ, SNS) stores the event and pushes it to any interested consumer. The core pieces are the producer, the event store/broker, and one or more consumers (often stateless micro‑services) that subscribe to specific event types. Events flow as immutable records—usually JSON or Avro—through topics/queues, and each consumer processes them at its own pace, often persisting state in its own database. Contrast that with request‑response, where a client calls an endpoint, waits for a synchronous reply, and the caller is tightly coupled to the callee’s availability and contract. The upside is big: loose coupling lets you scale producers and consumers independently, you get natural retry/​buffering, and you can build highly resilient pipelines (think order → payment → shipping → notification) without a single point of failure. You also gain flexibility for new features—just add another subscriber. The trade‑offs are the usual async headaches: you have to accept eventual consistency, handle message ordering and deduplication, and keep an eye on schema evolution. Debugging can feel like chasing ghosts because you’re not watching a single request stack trace. In practice I started with a single Kafka topic for domain events, made my consumers idempotent, and used the Confluent Schema Registry to lock down contracts. If you go all‑in, monitor consumer lag, set clear retention policies, and keep the event model simple—don’t try to model every tiny state change as a separate event unless you really need it. For deeper reading, check Martin Fowler’s “Event‑Driven Architecture” article and the book *Designing Event‑Driven Systems* (Ben Stopford).