Event Driven Design & Message Driven Design

Source: Dev.to

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, achieving high decoupling.

1. A service performs an action.
2. It publishes an event.
3. Zero or more consumers react independently.

Example: Order Service successfully creates an order and emits an event.

Potential consumers

• Inventory Service reduces stock
• Email Service sends confirmation
• Analytics Service tracks metrics

A common pitfall 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, which 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 (e.g., ProcessPayment, SendEmail, GenerateInvoice).
• The sender often expects processing to occur.

Flow

1. Sender sends a message.
2. Receiver processes it.
3. Optional response or acknowledgment.

Example: Order Service sends a ProcessPayment message to Payment Service.

---

Choosing Between EDD and MDD

A useful mental model is that one is reactive and the other is instructive:

• Reactive: “An order was placed.” (event)
• Instructive: “Place an order.” (message)

Most modern architectures combine both, where commands (messages) initiate work and events announce results.

Combined Example

Checkout Service
   ├─ sends → ProcessPayment (message)
   └─ publishes → PaymentCompleted (event)