Many teams eventually ask the same question: why should we introduce messaging? Direct calls between services are simple to understand and easy to implement, yet most non‑trivial systems eventually add messaging. This session explores why.

Messaging does not come without its own challenges. It introduces new concepts, operational complexity, and additional failure modes. Used without care, it can make systems harder to reason about and maintain. Used intentionally, however, messaging helps address architectural challenges that emerge as systems grow, become distributed, and evolve.

In this session, we step back to focus on the architectural reasons messaging exists. We examine when direct communication starts to break down and what problems messaging is designed to solve, such as decoupling components, handling scale mismatches, increasing resilience, and enabling asynchronous workflows. We also distinguish between different forms of messaging. Messages, events, and streams serve different purposes, and choosing between them shapes both system behavior and long‑term maintainability.

Attendees will leave with a clear understanding of when and why messaging belongs in an architecture, how to recognize the patterns it enables, and how to make more informed design decisions.