Event-driven architecture

Teams go event-driven when one fact, such as an order being placed, needs to set off work in several places and no single service should have to know about all of them. Publishing the event once and letting consumers react on their own keeps the services independent and the checkout fast.

Why does event-driven architecture matter?

• Loose coupling. The checkout service does not know that inventory, email and analytics exist. Adding a fourth consumer changes nothing upstream.
• Resilience. If the email service is down, the event waits in the broker until it comes back. The order still completes.
• Scalability. A burst of orders queues up in the broker rather than overloading every consumer at once.
• Auditability. The stream of events is a record of everything that happened.

What are the parts of an event-driven architecture?

• Events. Immutable records of something that happened, named in the past tense: “order placed”, “payment captured”. Each carries a small payload and a timestamp.
• Producers. The services that detect a change and publish an event. They do not wait for anyone to consume it.
• Event broker or stream. The infrastructure between producers and consumers. It accepts events, stores them durably and delivers them. Kafka, RabbitMQ and the managed services of each cloud are the usual choices.
• Topics. Named streams within the broker, one per event type or domain, that consumers subscribe to.
• Consumers. The services that subscribe to a topic and react, each with its own logic and data.
• Schema registry. A shared, versioned definition of each event’s shape.

What are the main event-driven patterns?

Pub/sub

A publisher sends an event to a topic and the broker delivers a copy to every subscriber. Subscribers come and go without the publisher knowing. This is the pattern in the hero diagram.

Event streaming

Events are appended to an ordered, durable log. Each consumer keeps its own offset, so a new consumer can replay a year of history and a slow consumer falls behind without blocking anyone.

Event sourcing

Instead of storing the current state of an order, the system stores every event that happened to it and rebuilds the state by replaying them. It gives a complete audit trail at the cost of more complex queries.

CQRS

Command Query Responsibility Segregation splits the model that handles writes from the model that answers reads. The write side emits events; the read side consumes them to build views shaped for queries.

How do you read an event-driven architecture diagram?

Follow the events, not the requests. In the order example at the top of this page, the customer calls the checkout service, which is the only synchronous, client-server step. Checkout saves the order and publishes an “order placed” event with the order ID, items and total to the broker.

Three consumers subscribe to that topic. The inventory service reserves stock, the email service sends a confirmation and the analytics service updates its dashboards, each on its own schedule, while checkout has already returned to the customer. Later, the payment service publishes “payment captured”, which analytics also consumes.

Every arrow out of the broker is dashed because it is asynchronous. The questions this raises are the ones that matter: what happens if inventory reserves stock twice because an event was redelivered, and how long can email lag before customers notice?

How do you design an event-driven architecture?

1. Name the events. List the business facts other parts of the system care about, in the past tense. If nobody consumes an event, do not publish it yet.
2. Define each event’s schema. Include an ID, a timestamp and the minimum data consumers need. Version it from day one.
3. Pick the pattern per flow. Pub/sub for fan-out, streaming where order or replay matters, event sourcing only where the audit trail is a requirement.
4. Make consumers idempotent. Brokers deliver at least once, so every consumer must handle the same event twice without side effects.
5. Decide on ordering. Partition by an entity key, such as order ID, when events about one entity must be processed in order.
6. Draw it. An architecture diagram with producers, topics and consumers is the clearest way to review who depends on what at the system architecture level.

What are common event-driven architecture mistakes?

• Events as commands. “Send email to customer” is a command aimed at one service. Publishing it as an event hides the coupling instead of removing it.
• Fat or anemic events. An event carrying the whole order changes every time the order does; one carrying only an ID forces every consumer to call back. Carry what consumers need.
• Assuming exactly-once delivery. Duplicates will happen. Consumers that are not idempotent will double-charge or double-ship.
• Everything asynchronous. Some operations need an answer now. Keep those as direct calls.

How does event-driven architecture compare with other styles?

Style	How parts communicate	Strength	Weakness
Event-driven	Events through a broker	Loose coupling, resilience, fan-out	Eventual consistency, harder debugging
Request-driven, as in a three-tier system	Direct synchronous calls	Simple, immediate answers	Tight coupling, cascading failures
Serverless	Events trigger functions	Scales to zero, no servers	Cold starts, vendor-specific triggers

Most real systems mix these: an API gateway in front of microservices that talk through events, with serverless functions as some of the consumers. A monolith can use the same patterns in process. Eraser’s engineering blog covers orchestration and the unhappy paths that come with this mix.

What tools help with event-driven architecture?

• Message brokers and streaming platforms. Kafka, RabbitMQ, Pulsar and their managed equivalents provide the durable, ordered delivery the architecture depends on.
• Schema registries and AsyncAPI. A registry versions event schemas; AsyncAPI documents topics and payloads the way OpenAPI documents REST endpoints.
• AI diagramming tools. Tools like Eraser turn a description of your producers, topics and consumers into an architecture diagram you can keep editing, so who publishes and who subscribes can be reviewed before any code is written.

For more on this kind of diagram, see architecture diagrams.

Frequently asked questions