When to use event-driven design

Event-driven design trades simple, immediate calls for loose coupling and independent scaling. The price is eventual consistency, harder debugging and more infrastructure to run. Whether it pays off depends on the problem.

A good fit

Events work well when several parts of the system react to the same fact. OrderPlaced can start Inventory, Notifications and an analytics feed without Orders knowing any of them. They also suit work that must not block the caller, load that comes in bursts and can be buffered, and consumers that should be able to fail and catch up without stopping the producer. Microsoft lists decoupled producers and consumers, multiple subsystems handling the same events and high volumes as the main reasons to use the style.

A poor fit

Sign	Why events do not help
A simple request and response	A synchronous call meets the need, and a broker, async errors and eventual consistency add cost for nothing
A rule that must hold across services at once	Events leave a window where services disagree
A small CRUD application	There are no separate consumers to decouple
A team new to asynchronous systems	Debugging, monitoring and recovery work differently, and the learning time lands on the delivery date

Hybrid is normal

Most systems use both. Orders can call Payments directly to authorise a card, because it needs the answer now, and then publish OrderPlaced for everyone else. Queries stay synchronous. Events carry facts that other parts react to later. Microsoft’s guidance says many applications combine the event-driven style with other styles, and a system does not have to choose one for everything.

Mistakes to avoid

A distributed monolith is a set of services that must change and deploy together. It happens when events carry so much of one service’s data that every consumer depends on its shape, or when an event chain is really a sequence of calls in disguise. Particular Software describes a large OrderPlaced event that leaves a monolith’s coupling in place across services, because any new requirement changes a contract that many services share.

Event sprawl is the other direction: a new event for every field change, until nobody can follow the flow. Microsoft warns that too many fine-grained events can overwhelm the system and hide the overall flow, and that merging them too far makes consumers do needless work. Microsoft suggests asking whether consumers need to look inside an event to decide what to do, and publishing fewer, more meaningful events when they do not.

Then there are assumptions about delivery. Do not assume global ordering: order holds at most per key or partition (see message orderingMessage orderingOrder exists only within one key, and only while one consumer handles that key at a time.Opens in a new tab). Do not assume exactly-once processing into your own database: plan for duplicates with idempotent consumersIdempotent consumersA consumer that gives the same result whether a message arrives once or five times.Opens in a new tab (see delivery guaranteesDelivery guaranteesAt-most-once, at-least-once and exactly-once: what a broker promises, and what it cannot.Opens in a new tab). And do not assume that a consumer has seen an event the moment it was published (see eventual consistencyEventual consistencyAfter a change, other services catch up later, and the design has to allow for the gap.Opens in a new tab).

What stays synchronous

Keep strong-consistency rules inside one service’s transaction, or behind a synchronous call. Selling the last unit of stock, keeping an account balance from going negative and enforcing a unique username are decisions that need the current answer, not a copy from a few seconds ago. If a rule spans services and cannot be relaxed, either put the data in one service or accept a sagaSagasA workflow made of local transactions, with an undo step for each one.Opens in a new tab with its compensations. The patterns in this trail, CQRSCQRSSeparate models for changing data and for reading it.Opens in a new tab and event sourcingEvent sourcingStore the events that happened, and work out the current state from them.Opens in a new tab included, each fit particular parts of a system.