Event-driven order processing
Checkout publishes one event to Kafka; payments, inventory and email each consume it at their own pace.
Click any box to open its page. Open it in the playground to rewire it, change the traffic or take parts down.
Instead of the checkout service calling payments, inventory and email one after another, and failing if any of them is slow, it records a single fact (“order placed”) in a Kafka topic and returns. Each downstream service reads the topic with its own offset. A slow email sender falls behind without holding anyone else up, and a new service can be added later and replay the history from the start.
How it flows
- 1
Checkout records one event
When an order is placed, checkout appends an
OrderPlacedevent, keyed by order id, to theorderstopic and responds to the customer. It doesn’t know or care who reads it.Checkout APIApache Kafka - 2
Each consumer keeps its own place
Payments, inventory and email are separate consumer groups. Kafka tracks an offset for each, so they read the same events independently and at different speeds.
- 3
Slow consumers catch up later
The email sender polls every couple of seconds and takes several events at once. It’s often behind, which is fine: the events wait in the topic, and nothing upstream slows down.
- 4
Results go to each service’s own store
Payments writes charges to its own PostgreSQL database. Services never share a database; if one needs another’s data, it reads the events or publishes its own.
Payments servicePostgreSQL
Why this shape works
- Services are decoupled in time: one being slow or down doesn’t break checkout
- Adding a consumer (fraud checks, analytics) needs no change to checkout
- The topic is a replayable history, useful for rebuilding a service’s state or backfilling a new one
- Keying by order id keeps each order’s events in order within a partition
Where it strains
- Consumers must be idempotent: after a crash, Kafka redelivers events since the last committed offset
- Eventual consistency: right after checkout, inventory may not have reserved stock yet
- Tracing one order across services needs correlation ids and good observability
- Event schemas become a contract between teams; change them carefully, with a schema registry and Avro or Protobuf
Common swaps
On AWS without running Kafka: publish to SNS and fan out to one SQS queue per service, or use EventBridge rules.
If the steps must happen in order with compensation on failure (refund if stock runs out), use a workflow engine instead.
To avoid losing events when the database write succeeds but the publish fails, write to an outbox table and stream it to Kafka with change data capture.
Built from
Apache KafkaOpen sourceEvent streamsThe open-source distributed log that most event streaming is built on, or built to be compatible with.
PostgreSQLOpen sourceRelational databasesThe open-source relational database that most new projects start on, extensible enough to grow into many niches.
AWS LambdaAWSServerless functions (FaaS)AWS’s functions service: upload a handler, connect a trigger, and pay per request and per millisecond.