Integration Patterns Across Services

Integration patterns decide whether event-driven systems create useful autonomy or simply hide old coupling behind a broker. The important question is not whether one service publishes a message. It is whether the chosen pattern matches the dependency shape between producers and consumers.

Read the lessons in order. The first covers notification events, which are lightweight but can push consumers into callback traffic. The second explains event-carried state transfer, where richer events improve autonomy at the cost of a heavier contract. The third turns to correlated request-reply, which uses messaging while still preserving a response relationship. The fourth covers aggregation and scatter-gather, where one upstream request or event fans out to multiple downstream handlers and later combines the results.

If a team says “we use events for integration” but cannot explain what kind of dependency each interaction still creates, Chapter 10 is where that integration model needs to become explicit.

In this section

• Event Notification
  A practical lesson on notification-style events, including when they preserve useful decoupling and when they quietly recreate callback-heavy integration.
• Event-Carried State Transfer
  A practical lesson on publishing enough state in events for downstream autonomy, including the trade-off between fewer callbacks and a heavier external contract.
• Correlated Request/Reply
  A practical lesson on request-reply over messaging, including correlation IDs, reply channels, and when the pattern is a fit versus a disguised form of RPC.
• Aggregation and Scatter-Gather
  A practical lesson on fan-out and result collection patterns, including completion policies, partial results, timeouts, and the trade-offs in composite responses.