Event Notification

Event notification is the lightest event-driven integration pattern. The producer tells the rest of the system that something happened, but does not try to publish the full state needed by every consumer. That can be a strong choice when downstream systems only need a trigger or when the producer should remain narrow in what it exposes. It becomes weaker when most consumers immediately call back to the producer for details.

The pattern is attractive because it keeps the event contract small. The trade-off is that it often preserves data dependency at runtime. If five consumers all react to order.placed by calling the order service for the same details, the architecture is asynchronous at transport level but still tightly coupled at availability level.

    sequenceDiagram
	    participant O as Order Service
	    participant B as Broker
	    participant F as Fulfillment
	    participant A as Analytics
	
	    O->>B: Publish order.placed
	    B-->>F: order.placed
	    B-->>A: order.placed
	    F->>O: Fetch order details
	    A->>O: Fetch order details

What to notice:

• the producer publishes only a change signal
• downstream services still depend on source-service availability for detail
• callback volume grows with the number of consumers

When Notification Is a Good Fit

Notification works well when:

• the event mainly tells another system that refresh or follow-up work should start
• consumers need only a small identifier and can tolerate a later detail fetch
• the producer should avoid exporting a broad external data model
• downstream consumers are few, controlled, and not latency sensitive

This often fits cache invalidation, simple audit signals, or workflows where the consumer already owns enough context locally.

When Notification Starts to Smell

The pattern starts to degrade when:

• many consumers all fetch the same details after every notification
• the producer becomes a read hot spot because notifications fan out into callback traffic
• the source service outage now blocks downstream handling even though the system “uses events”
• consumers cannot reason usefully about the event without immediate remote reads

At that point, the system may need event-carried state transfer, a projection, or a dedicated read model instead of pure notification.

1{
2  "eventName": "order.placed",
3  "eventId": "evt_0184",
4  "data": {
5    "orderId": "ord_441"
6  }
7}

This is a valid notification event. The question is whether orderId is enough for consumers to act locally, or whether it only triggers a second dependency chain.

Notification Is Still a Contract

Even when the payload is small, notification is not contract-free. Consumers still depend on:

• the event name and meaning
• the identifiers included
• the guarantee that a corresponding resource exists or is queryable
• how long the source system keeps the referenced details available

This is why a notification event should be intentionally narrow, not vague. A thin payload is useful only if it still identifies a clear business fact.

Common Mistakes

• using notification by default even when nearly every consumer needs the same full context
• assuming smaller payloads always mean looser coupling
• omitting stable identifiers and forcing consumers into fragile lookup patterns
• hiding synchronous dependency behind event publication
• treating notification as a complete integration strategy rather than as one pattern among several

Design Review Question

A team publishes invoice.ready notifications with only invoiceId. Six downstream services immediately call the billing service for amount, currency, due date, and customer details. What should you challenge first?

Challenge whether notification is the right integration pattern for this interaction. The repeated callback behavior suggests the event is too thin for the actual consumer needs, and the architecture may still be tightly coupled to billing-service availability.

Quiz Time