Skip to content
System Design Explainer
← All concepts

Messaging & flow

Event-driven architecture

Services publish events about what happened; others react asynchronously.

Instead of the order service calling shipping, email and analytics directly, it publishes 'order placed' to a durable log. Each consumer reads at its own pace, so the producer stays fast and new consumers can be added without changing it.

See it in action

Step through the scenarios on the diagram.

Laying out diagram…

1/4The order service appends OrderPlaced to the log and moves on — it doesn't wait for anyone.

Order service
— Producer
Event log
— Durable, ordered, replayable
Email service
— Consumer group 1
Search indexer
— Consumer group 2
Analytics
— Consumer group 3

How it works

  • A partitioned, replayable log (Kafka-style) keeps events in order per key.
  • Consumers track their own offsets and can replay history to rebuild state.
  • Use an outbox table so a DB write and its event are published together.

Trade-offs

  • Eventual consistency: consumers lag behind the producer.
  • Debugging spans many services; needs good tracing.
  • Consumers must be idempotent because events can be delivered more than once.

Seen in

Components involved

Event streaming

Related concepts

IdempotencyFan-out (push vs pull feeds)Change data captureBack-pressure & queues