Event Sourcing: Decouple Microservices with Domain Events

Traditional microservice designs often chain synchronous calls: an order service calls inventory, then logistics, then loyalty points. Every new requirement forces changes to the upstream service, creating tight coupling that makes the system fragile and hard to extend.

Traditional Synchronous Chain vs. Event Sourcing

In the synchronous model,

User places order → call inventory deduction → call logistics dispatch → call loyalty points

. All logic is strung together; a change anywhere ripples through the whole chain.

Event sourcing flips this: the upstream service only publishes a domain event (e.g., OrderPlaced). Downstream services — inventory, logistics, loyalty — each subscribe independently and decide their own reaction. Adding a new downstream action requires zero changes to the order service; the new subscriber simply listens for the event.

Four Core Elements of a Domain Event

Every domain event must carry:

event_id — unique identifier such as createOrder, describing what happened .

publisher — the emitting service name, e.g., service_order, telling who emitted it .

publish_time — millisecond-precision timestamp for ordering and traceability.

data — business payload: domain object, array, map, or even empty for pure state-change signals.

The publisher defines the event contract (event_id + data schema) and communicates it to all subscribers. Subscribers parse and handle the payload independently, with no cross-dependency.

Complete Publish–Subscribe Flow

Publish : After the business operation completes, call publish() — e.g., createOrderEvent.publish(serviceName, order) — a single line of code.

Middleware handling : The technical platform (built on Spring Cloud Stream) simultaneously persists the event to a database for audit/traceability and forwards it to a message broker (RabbitMQ or Kafka). Publishers and subscribers remain unaware of the underlying broker details.

Subscribe & apply : Each subscriber receives the event from the queue and implements its own apply() method. For example, a restaurant notification service alerts the restaurant, while an order tracking service updates status. They operate in complete isolation.

Critical practice : Publish every domain event even if no subscriber exists today. Requirements evolve; tomorrow a new service may need that event.

Practical Implementation Template

Identify events : Use event storming to enumerate every key business fact (e.g., UserPlacedOrder, RestaurantAcceptedOrder, CourierPickedUp).

Define contracts : For each event, fix the event_id, publisher, and data structure — this becomes the publisher/subscriber agreement.

Upstream publish : At the end of the business method, invoke publish(); the platform handles queue dispatch and DB recording.

Downstream subscribe : Each subscriber implements apply() to perform its independent follow-up logic.

Publish all events : Never guess which events are “unlistened”; emit every domain event unconditionally.

One-Sentence Takeaway

Event sourcing boils down to eight Chinese characters: 上游发布，下游各自定义 — upstream publishes, downstream each customizes. It breaks apart formerly coupled workflows so complex systems become like Lego bricks: independently developed, deployed, and changed.