Event-Driven Architecture
- In Turkish
- Olay Güdümlü Mimari
In short
Event-driven architecture is a software design style in which services communicate by producing and reacting to events, such as an order being placed.
What is event-driven architecture?
In an event-driven architecture, components communicate by announcing that something has happened rather than by calling each other directly. An event is a record of a fact, such as OrderPlaced or UserSignedUp, usually with a small payload of data. Producers publish events, and any number of consumers can react to them independently.
Events usually travel through an event broker, such as a message queue or an event streaming platform, which stores them and delivers them to subscribers. When an order is placed, for example, the order service publishes a single event, and the payment, inventory, email, and analytics services each react in their own way. The order service doesn't know or care who is listening, so new consumers can be added without changing it.
An analogy is a fire alarm: once it goes off, people leave the building, the fire department is called, and the elevators stop, all without the alarm knowing about any of them. Event-driven architecture is common in microservices, real-time systems, connected devices, payment processing, and anywhere slow work should happen in the background instead of making the user wait.
The trade-off is that the system becomes asynchronous and eventually consistent: different services may briefly disagree about the current state, and following one request across many events requires good logging and tracing. Consumers must also handle duplicate or out-of-order events, which is why idempotent handlers are important. Event-driven architecture is different from the observer pattern, which works inside a single program, and from request-response APIs, where the caller waits for an answer.
Key takeaways
- Components communicate by publishing and consuming events.
- Producers don't know which consumers exist, which keeps services loosely coupled.
- An event broker or message queue stores and delivers the events.
- Systems become asynchronous and eventually consistent.
- Consumers should be idempotent because events can arrive more than once.
Example
// broker is a placeholder for a message queue or event streaming client
// Producer: the order service announces what happened and moves on
await broker.publish("order.placed", { orderId: "A-1001", total: 59.9 });
// Consumers: each service reacts independently to the same event
broker.subscribe("order.placed", async (event) => {
await sendConfirmationEmail(event.orderId);
});
broker.subscribe("order.placed", async (event) => {
await reserveStock(event.orderId);
});Readers ask
What is the difference between event-driven architecture and request-response?
In request-response, a caller sends a request to a specific service and waits for a reply. In event-driven architecture, a producer publishes an event without waiting, and any interested services react to it on their own schedule.
What is an event broker?
An event broker is the infrastructure that receives events from producers, stores them, and delivers them to consumers. Message queues and event streaming platforms are common examples.
What is eventual consistency?
Eventual consistency means that after a change, different parts of a system may show different data for a short time, but they all catch up once the related events have been processed. It is a common trade-off in event-driven and distributed systems.
See also
- Message QueueBackend & APIs, p. 29A message queue is a component that stores messages from one service until another is ready to process them, so parts of a system can work asynchronously.
- MicroservicesSoftware Architecture, p. 27Microservices are an architectural style where an application is split into small, independently deployable services that communicate over a network.
- Observer PatternSoftware Architecture, p. 31The observer pattern is a behavioral design pattern in which an object, the subject, automatically notifies a list of subscribers whenever its state changes.
- WebhookBackend & APIs, p. 47A webhook is an automated HTTP request that one application sends to a URL you provide as soon as a specific event happens, such as a completed payment.
- IdempotencyBackend & APIs, p. 24Idempotency is the property of an operation that produces the same result whether it runs once or many times, so accidentally repeating a request is safe.
- CQRSSoftware Architecture, p. 10CQRS is an architectural pattern that separates the code that changes data, called commands, from the code that reads data, called queries, into two models.
Spotted a mistake or something missing on this page?Suggest an edit