Skip to main content
Architecture & Engineering

Event-Driven Architecture

Event-driven architecture is a design where components publish events describing something that happened, and other components react to them, without the publisher knowing who is listening. It decouples systems: adding a new reaction to an existing event requires no change to the code that emits it.

The extensibility is genuine. When an order-placed event already exists, adding an inventory update, a loyalty calculation and an analytics record means adding three subscribers and modifying nothing. In a request-response design, each of those would be another call inside the ordering code.

What you trade away is traceability. There is no call stack showing what happened in response to an event, so understanding a flow means reading subscriber registrations across services. Without distributed tracing and a documented event catalogue, teams reach a point where nobody can confidently say what a given event triggers — which is when the decoupling starts costing more than it saves.

FAQ

Event-Driven Architecture
FAQ.

Common questions about event-driven architecture.

Ask Us Anything

When the flow is genuinely sequential and every step must succeed before the next begins. Forcing a linear transaction into events adds eventual consistency and compensating logic to a problem a database transaction solved cleanly. Events suit fan-out — one thing happened, several unrelated systems care — not step-by-step orchestration.