Event-driven architecture
ee-VENT DRIV-en AR-kih-tek-cher
A design pattern where systems communicate by producing and consuming events instead of direct calls.
In event-driven architecture, services communicate by publishing events (things that happened) rather than calling each other directly. When a user places an order, the order service publishes an "OrderPlaced" event. The payment service, the inventory service, and the notification service each listen for that event and react independently. No service needs to know about the others.
This is the opposite of the request-response pattern where the order service would call the payment service, then call the inventory service, then call the notification service sequentially. If one of those services is down, the entire operation fails. In an event-driven system, the event is published to a message broker (Kafka, RabbitMQ, Amazon SNS/SQS), and each consumer processes it when ready. If the notification service is down for 5 minutes, it catches up when it comes back.
The trade-off is complexity. Debugging a request-response chain is straightforward: follow the call stack. Debugging an event-driven system requires tracing events across services, understanding message ordering, handling duplicate events (idempotency), and dealing with eventual consistency. Event-driven architecture shines in systems with many independent services that react to the same events, but it is overkill for simple applications.
Examples
An e-commerce platform decouples order processing.
When a customer places an order, the order service publishes an OrderPlaced event to Kafka. Five services consume the event independently: payments charges the card, inventory reserves the items, shipping creates a label, analytics records the sale, and notifications sends the confirmation email. If the shipping service is slow, payments and notifications still process instantly. Adding a sixth consumer (a loyalty points service) requires zero changes to the order service.
A fintech company uses events for audit trails.
Every action in the system produces an event: AccountOpened, FundsDeposited, TransferInitiated, TransferCompleted. These events are stored in an append-only event log (Kafka with infinite retention). The audit team can reconstruct the complete history of any account by replaying its events. When regulators ask 'what happened to account X on March 15?', the answer is in the event log, timestamped and immutable.
A team migrates from synchronous to event-driven processing.
The monolithic application calls the email service synchronously during signup. If the email service is slow (3 seconds), the signup page is slow (3 seconds). The team publishes a UserRegistered event instead. The email service consumes the event asynchronously. Signup response time drops from 3.5 seconds to 200ms. The user sees the welcome page immediately. The welcome email arrives 5 seconds later.
In practice
Read more on the blog
Frequently asked questions
What is the difference between event-driven architecture and message queues?
A message queue is a tool. Event-driven architecture is a pattern. Message queues (RabbitMQ, SQS) are one way to implement event-driven architecture, but not the only way. Kafka is an event log, not a traditional queue. Webhooks are event-driven but do not use a queue at all. Event-driven architecture is the design principle: services communicate through events. Message queues, event logs, and webhooks are the tools you use to build it.
How do you handle ordering in event-driven systems?
Kafka guarantees ordering within a partition. If you need all events for a specific order to be processed in sequence, send them to the same partition (using the order ID as the partition key). Across partitions, there is no ordering guarantee. For most systems, partition-level ordering is sufficient. If you need global ordering, you are usually better off with a traditional database and request-response pattern. True global ordering at scale is extremely expensive.
Related terms
A system that stores and delivers messages between services, allowing asynchronous communication.
An architecture where an application is built as a collection of small, independent services.
An HTTP callback that sends data to your application automatically when an event occurs in another system.
The property where performing an operation multiple times produces the same result as performing it once.
Application programming interface: a defined way for software programs to communicate with each other.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.