Grokking Events in System Design: What They Are and What to Include

This post demystifies events in event-driven microservices architecture, comparing thin vs. fat event payloads and sharing tips to keep your systems loosely coupled.

Imagine your microservices don’t call each other directly, but instead broadcast messages about things that happen.

That’s the idea behind event-driven architecture (EDA).

One service emits an event (a message that “something happened”), and other services interested in that event can react to it asynchronously. This decouples services and helps systems scale.

But it raises a key question: what information should an event carry?

For example, an OrderPlaced event in an e-commerce app could prompt the shipping service to pack the order and the notification service to email a confirmation – all triggered by one event without direct calls between services.

So, what goes inside an event like OrderPlaced?

Should it just contain an order ID, or include all the details of the order (items, prices, customer info, etc.)?

In practice, system designers typically choose one of two approaches:

Approach 1: The Thin Event (Only an ID)

Keep events minimal.

Our OrderPlaced event might include only an order ID (say { order_id: 1234 }).

Any service that receives this event and needs more data would then call back to the Order Service to fetch those details.

This makes the event lightweight, but thin events have drawbacks:

• Coupling via lookups: Every consumer must contact the Order Service for details. Your “decoupled” microservices become indirectly coupled since they all rely on the Order Service for info.

• Extra network calls: If multiple services get the event, each one calls the Order Service for data. That’s a lot of duplicate traffic. These calls add latency and can overwhelm the Order Service under load.

In short, a thin event saves on message size, but shifts complexity (and load) onto the consumers and the source service.

Approach 2: The Fat Event (Full Details)

Alternatively, make events self-contained.

A “fat” event carries the details so listeners don’t need to ask anyone else.

Our OrderPlaced event would then include not just the order ID, but everything a subscriber might need – item details, prices, customer info, shipping address, etc.

Detailed events have benefits:

• Looser coupling: Consumers don’t need to call the Order Service; they can act independently with the data in the event.

• Fewer calls: No matter how many services receive the event, it’s one broadcast message. There’s no flurry of follow-up requests, meaning less chatter and lower latency overall.

However, fat events come with trade-offs:

• Bigger messages: Each event is larger. Message brokers (Kafka, RabbitMQ) have size limits, and hefty events use more bandwidth. Be mindful of event size.

• Schema evolution: More fields mean a tighter schema contract with consumers. If you change the event format later, you could break consumers. Plan for versioning to maintain compatibility.

• Data duplication: A detailed event duplicates data from the source service (often an acceptable cost for decoupling).