We often introduce message brokers when building distributed systems, but do we always need one?

HTTP is simple, familiar, and often exactly what an application needs. But as systems grow, synchronous communication can introduce tight coupling, cascading failures, slow workflows, and problems when downstream services are temporary unavailable.

In this talk, we'll look at the practical situations where asynchronous messaging starts to make sense. Using examples from a .NET application, we'll explore how message brokers can help with decoupling services, handling temporary failures, processing long-running work, distributing events to multiple consumers, and absorbing traffic spikes,

We'll also look at the complexity it introduces: retries, dead-letter queues, idempotency, ordering, observability, eventual consistency, message contracts, and the transactional outbox pattern.

The goal is not to convince you to use a message broker, but to give you a practical way to decide when HTTP is enough and when messaging is worth the additional complexity.

By the end of the session, you'll have a set of questions and trade-offs you can apply to your own architecture before reaching for RabbitMQ, Azure Service Bus, or another messaging platform.