Event-Driven Architecture for Beginners

Events, commands and messages

Both travel as messages over queues or streams (posts 35–36). A publisher is the service that sends an event. A subscriber is a service that asks to receive it.

Name events as past-tense business facts: OrderPlaced, PaymentCaptured, ShipmentDispatched, UserEmailChanged. Avoid names that describe technical details, like OrderTableRowUpdated.

The basic event-driven flow

• The order service is now simple: save the order, publish the event (using the outbox pattern, post 37).
• New features just subscribe. Adding a fraud check means no change to the order service.
• A slow or broken loyalty service no longer affects checkout. Its events wait in the stream until it recovers.

Four patterns that are all called "event-driven"

Martin Fowler pointed out that "event-driven" can mean four different things. Here they are one by one.

1. Event notification. The event is small. It only says that something happened. Consumers call back to ask for the details if they need them.

{ "type": "OrderPlaced", "orderId": "5521" }

• ✅ Small events, loose coupling.
• ❌ Consumers call the order service's API. This adds load, and the consumers now depend on the order service while they run.

2. Event-carried state transfer. The event carries all the data that consumers need.

{ "type": "OrderPlaced", "orderId": "5521", "userId": 42,  "items": [{"productId": 991, "qty": 1, "price": 129900}], "total": 129900, "city": "Pune" }

• ✅ Consumers do not need to call back. They can even keep their own local copy of the data.
• ❌ Bigger events and duplicated data (post 23). Schema evolution (changing the event format over time without breaking readers) becomes important.

3. Event sourcing. Normally you store only the current state (for example, the balance). With event sourcing you store every event that ever happened. You work out the current state by replaying (re-reading) them in order. A bank statement works like this.

• ✅ A full audit history (a record of who did what and when), and "time travel" (what was the state last Tuesday?). You can also build new views by replaying events.
• ❌ More complex, and changing the format of old events is tricky. Long histories need snapshots (a saved copy of the state at one moment, so you do not replay everything). To ask "what is the current state?" you need projections (tables built by replaying the events).
• Good for: ledgers, banking, and areas with many audit rules. Too much for most CRUD apps (apps that only create, read, update and delete records).

4. CQRS (Command Query Responsibility Segregation). This is a design that uses separate models for writing (commands) and reading (queries). Writes go to a model built for correctness. Events then update one or more read models built for fast queries: a search index, a denormalised feed (data copied into one ready-to-read shape), or a reporting table (post 23).

Event sourcing and CQRS are often used together. You can also use either one alone.

Choreography vs orchestration

When a business process spans several services (like checkout), who is in charge of the steps?

Choreography means services react to each other's events, like dancers who each know their own moves. Nobody is in charge.

• ✅ Very decoupled, with no central bottleneck.
• ❌ You cannot see the whole flow. It is spread across many services, so it is hard to answer "where is order 5521 stuck?". Circular dependencies (A waits for B, and B waits for A) can appear by accident.

Orchestration means a central coordinator (the orchestrator) tells each service what to do with commands, and tracks the progress. It is like a conductor of an orchestra.

• ✅ The flow is clear and in one place. It is easy to monitor, change and debug.
• ❌ The orchestrator is an extra part to run, and the services stay somewhat tied to it.

Rule of thumb: use choreography for simple reactions that are only loosely related (send an email, update analytics). Use orchestration for important business processes with many steps (checkout, loan approval, onboarding). Workflow engines like Temporal or AWS Step Functions are often used as orchestrators (post 38).

Sagas: transactions across services

A monolith is one big application with one database. There, checkout can be one database transaction (a group of steps that all succeed or all fail, post 21). With many services, each with its own database, you cannot do that. A saga is a sequence of local transactions (one per service). Each step has a compensating action, which is a step that undoes it if a later step fails.

Example: the checkout saga when payment fails.

Important points:

• Compensations are business actions, not automatic rollbacks (a rollback is a database undo). Examples: "refund", "release", "cancel", "send apology email".
• Every step and compensation must be idempotent (safe to run twice, post 37), because they may be retried.
• Users may see in-between states ("Order pending…"), so design the screens for that.
• Sagas can be choreographed (via events) or orchestrated (via a coordinator). Orchestration is usually easier to reason about for sagas.

Change Data Capture (CDC) as an event source

Sometimes you cannot, or do not want to, change old applications so that they publish events. Change Data Capture (CDC) is a technique that reads the database's change log (post 21) and turns every insert, update and delete into an event. CDC tools like Debezium send these events to Kafka. CDC is also a reliable way to build the outbox pattern (post 37).

Event schemas and evolution

Events are a contract between teams, just like APIs (post 34). A contract is a promise about the shape of the data:

• use a schema (a written description of the fields in an event, for example in Avro, Protobuf or JSON Schema) and a schema registry (a service that stores schemas and rejects changes that would break readers),
• make changes backward compatible, so old readers still work. Add optional fields. Never remove a field that consumers use, and never give it a new meaning,
• include standard metadata: event ID (for dedup), type, version, timestamp, source, and a correlation ID (one ID shared by all events from the same user action, used for tracing). The CloudEvents standard defines a common format for this.

{  "id": "evt-8f2a1c",  "type": "com.shop.order.placed",  "specversion": "1.0",  "source": "order-service",  "time": "2027-02-11T10:15:00Z",  "datacontenttype": "application/json",  "data": { "orderId": "5521", "userId": 42, "total": 129900 }}

The challenges

• Eventual consistency. This means data in different places is not updated at the same moment, but it becomes the same after a short time. After you place an order, the loyalty points appear a second later. The UI must show "processing" states.
• Debugging and visibility. One user action starts a chain of events across services. To follow it you need correlation IDs and distributed tracing (tools that show one request as it moves through many services, Part 8).
• Ordering. Use per-key ordering (events with the same key, such as the order ID, go to the same partition) and version numbers in events (posts 35–37).
• Duplicates. At-least-once delivery means a message may arrive twice. So idempotent consumers are a must.
• Replay side effects. Replaying events to rebuild a read model is useful. But make sure a replay does not resend emails or charge cards again.
• "Event soup". This means too many badly named events that overlap and have no owner. Keep an event catalogue (a list of all events) with a clear owner for each.