Introduction
Event-driven architecture is a style in which the components of a system communicate through events rather than by calling one another directly. An architectural style is a general approach to how the parts of a system are arranged and interact. An event is a structured record that describes something that has already happened, for example an order that has been placed. This guide explains what event-driven architecture is, why it exists, how it operates, and the situations in which it is appropriate.
What is it?
In an event-driven system, a component that detects a change publishes an event, and other components react to that event. The component that publishes an event is called a producer. A component that reacts to an event is called a consumer. The producer and the consumer do not call each other directly. Instead, events are delivered through an intermediary that is often called an event router or event broker. Because the producer does not know which consumers will react, the components are said to be loosely coupled. Coupling is the degree to which one component depends on another.
Why does it exist?
When components call one another directly and wait for a reply, they become tightly coupled. If one component is slow or unavailable, the components that depend on it are affected, and adding new behavior often requires existing components to be modified. Event-driven architecture was adopted so that components could be decoupled. A producer emits an event and continues its work, and any number of consumers can react independently. New consumers can be added without the producer being changed, which improves scalability, resilience, and extensibility.
How it works
A producer emits an event to an event router, and the router delivers the event to the interested consumers. On AWS, several services perform the routing role. Amazon EventBridge is an event bus that routes events according to rules. An event bus is a channel through which events are sent and matched to targets. Amazon Simple Notification Service, known as Amazon SNS, delivers a message to many subscribers at once, a pattern called fan-out. Amazon Simple Queue Service, known as Amazon SQS, holds messages in a queue until a consumer is ready to process them. A queue is a buffer that stores messages in order of arrival.
Two coordination patterns are common. In choreography, each consumer reacts to events on its own and no central controller exists. In orchestration, a central workflow directs the sequence of steps, a role for which AWS Step Functions is often used.
Architecture diagram
Advantages
- Loose coupling. Producers and consumers can be changed independently.
- Scalability. Consumers can be scaled separately according to their own load.
- Resilience. A slow or failed consumer does not block the producer.
- Extensibility. New consumers can be added without existing components being modified.
Disadvantages
- Harder to trace. A single business action may flow through many components, which makes debugging more difficult.
- Eventual consistency. Because reactions happen asynchronously, different parts of the system may be briefly out of step.
- Ordering and duplication. Events may arrive out of order or more than once, and consumers must account for this.
- Operational complexity. More services and monitoring are required than in a simple request and response design.
Common use cases
- Integration between microservices, in which each service reacts to the events of others.
- Real-time processing, in which data is acted upon as soon as it arrives.
- Fan-out notifications, in which a single event is delivered to many subscribers.
- Decoupling of slow work, in which a queue absorbs bursts of traffic.
Best practices
- Events should be designed to describe facts about the past rather than commands to a specific consumer.
- Consumers should be made idempotent so that a duplicated event causes no additional effect. Idempotent means that repeating an operation produces the same result.
- An event schema should be defined and versioned so that producers and consumers can evolve safely. A schema is the agreed structure of an event.
- A dead-letter queue should be configured so that messages that cannot be processed are preserved for investigation.
Common mistakes
- Consumers depend on hidden knowledge of the producer, which reintroduces the coupling that events were meant to remove.
- Idempotency is not implemented, so duplicated events cause duplicated effects.
- No dead-letter queue is configured, so failing messages are lost or retried endlessly.
- Events are used for simple, synchronous request and response, where a direct call would be clearer.
Related AWS services
- AWS Lambda is a common consumer that runs code in response to an event.
- Amazon EventBridge routes events between services according to rules.
- Amazon SNS delivers a message to many subscribers at once.
- Amazon SQS holds messages in a queue until a consumer is ready.
- AWS Step Functions orchestrates a sequence of steps when central coordination is required.
Frequently Asked Questions
- What is an event in event-driven architecture?
- An event is a structured record that describes something that has already happened, for example an order that has been placed. An event states a fact about the past and does not instruct any particular component to act.
- How does event-driven architecture differ from request and response?
- In request and response, one component calls another directly and waits for a reply, which couples the two together. In event-driven architecture, a producer emits an event without knowing which components will react, and consumers respond independently.
- What is the difference between choreography and orchestration?
- In choreography, each component reacts to events on its own and no central controller exists. In orchestration, a central workflow directs the sequence of steps. AWS Step Functions is commonly used for orchestration.
- What is a dead-letter queue?
- A dead-letter queue is a separate queue to which a message is moved after it has failed to be processed a set number of times. It prevents endless retries and preserves the message so the failure can be investigated.
- Is the order of events guaranteed?
- Not always. Ordering depends on the service that is used. Consumers should be designed so that events that arrive out of order or more than once are handled correctly.
This article is the summary. The book is the full, continuously updated reference: event-driven patterns, messaging services, error handling, and complete serverless architectures.
View the book