Event-Driven Architecture

One-liner: Services communicate by publishing facts (events) to a broker instead of calling each other; consumers react asynchronously and the system becomes eventually consistent.

Say this#

SAY THIS

Event — immutable fact that happened (OrderPlaced), past tense; vs command (PlaceOrder, imperative, one receiver).
Pub/sub — publisher emits to a topic; many independent subscribers receive.
Broker / event bus — Kafka, RabbitMQ, SNS+SQS, Google Pub/Sub, NATS, Redis Streams.
Event notification — thin event with an ID; consumer calls back for details.
Event-carried state transfer — fat event with the data; consumers keep local copies.
Event sourcing — the append-only event log is the source of truth; state is a fold over events.
Projection / read model / materialized view — derived state built from events.
CQRS — Command Query Responsibility Segregation: separate write model and read model(s).
Snapshot — periodic state checkpoint so replays don't start from event zero.
Replay — rebuild a projection by re-consuming the log.
Eventual consistency — read models lag the write model.
Choreography vs orchestration — see sagas; emergent flow vs central coordinator.
Schema registry — Avro/Protobuf schemas with compatibility rules (Confluent Schema Registry).

How it works#

TEXT

[Order Service] --OrderPlaced--> [Kafka topic: orders] --> [Inventory Svc]                                                        --> [Email Svc]                                                        --> [Analytics / warehouse]                                                        --> [Search indexer -> Elasticsearch][Order Service] --OrderPlaced--> [Kafka topic: orders] --> [Inventory Svc]
                                                        --> [Email Svc]
                                                        --> [Analytics / warehouse]
                                                        --> [Search indexer -> Elasticsearch]

Event sourcing + CQRS:

Command → validate against current aggregate state → append events to the event store.
Events published; projectors update read models (Postgres table, Redis, Elasticsearch).
Queries hit read models only; writes never read from them.
New requirement? Add a projector and replay history.

Reliability: publish via transactional outbox; consumers are idempotent; dead-letter queue for poison messages.

Trade-offs#

Choice	Pro	Con
Events vs sync RPC	Decoupling, resilience to downstream outage, fan-out for free	Eventual consistency, harder debugging, no immediate response
Event sourcing	Full audit log, temporal queries, replay	Schema evolution of old events, storage growth, learning curve
CQRS	Independent scaling and optimal models per side	Two models to maintain, read lag
Fat events	Consumers autonomous	Payload bloat, duplicated data drift
Thin events	Small, always-fresh	Callback traffic, coupling to producer API

Numbers#

Kafka: millions of messages/s per cluster; single partition order of tens of MB/s and strictly ordered.
End-to-end event latency: typically 5-50 ms in-datacenter; read model lag usually sub-second.
Retention: Kafka default 7 days; event stores retain forever (compaction or snapshots).

Say this#

How it works#

Trade-offs#

Numbers#

In the interview#