Event Driven Design (EDD)
Before we dive into EDD, let’s define an event. An event is immutable and represents a state change in the past.
The core idea of EDD is that systems react to events, facts that something has already happened. In EDD, producers don’t know who consumes the events, hence achieving high decoupling.
Typical flow
- A service performs an action
- It publishes an event
- Zero or more consumers react independently
Example: Order Service successfully creates an order, and emits an event.
The consumers in this scenario could be:
- Inventory Service reduces stock
- Email Service sends confirmation
- Analytics Service tracks metrics
Common Misconception
A common pitfall of developers is expecting replies from events. Events are one-way notifications, not conversations. When you publish an event, you are saying “this happened”, not “please respond”.
Message Driven Design (MDD)
Unlike EDD that reacts to things that have already happened, MDD instructs services to perform actions. These systems send messages to request work from another system.
Messages are intent-based (eg. ProcessPayment, SendEmail, GenerateInvoice) and sender often expects processing to occur.
Typical flow
- Sender sends a message
- Receiver processes it
- Optional response or acknowledgment
Example: Order Service sends a ProcessPayment message to Payment Service
When to use EDD or MDD?
A useful mental model for choosing between the two is that one is reactive and the other is instructive: ‘an order was placed’ versus ‘place an order’. Most modern architectures combine both, where commands initiate work and events announce results.
Example
Checkout Service
├─ sends → ProcessPayment (message)
└─ publishes → PaymentCompleted (event)
