阅读中文版本

Message Broker

A message broker mediates asynchronous communication, providing persistence, routing, and delivery guarantees between producers and consumers.

Definition

A message broker is middleware that receives messages from producers, stores and routes them according to rules, and delivers them to consumers, decoupling the two sides in time and knowledge.

It is used for durable work queues, event distribution, and buffering between services with different throughput. Compared to simpler alternatives, this concept fits best when the trade-off it represents is the one the system actually cares about.

When to use it

A common use case is applying it at the boundary where the cost of getting it wrong is highest, and the scenario usually involves a concrete guarantee the system must uphold. Unlike an ad hoc approach, it makes that guarantee explicit, reviewable, and testable.

How it works

Brokers add value through durability, routing, and back-pressure, but each has its own semantics for acknowledgement, ordering, and redelivery that applications must understand.

A queue that accumulates because consumers lag is an operational signal, so depth and age should be alerted rather than discovered after an outage.

Trade-offs and alternatives

A dead letter queue captures messages that cannot be processed, preventing a poison message from blocking progress while preserving it for inspection. The main drawback is the extra complexity it introduces, so the benefit should clearly outweigh that cost before a team adopts it.

Common misconceptions

A persistent misconception is that a broker removes the need to think about delivery semantics. Another is that queueing guarantees messages are processed in publish order. For example, an engineer who assumes otherwise may design around a guarantee that does not actually exist, which only becomes obvious under load or failure.

Anti-patterns to avoid

Two recurring anti-patterns are to ignoring the broker’s persistence settings and assuming durability and to letting an unbounded queue grow without monitoring or a dead letter path. Both tend to surface as hard-to-debug production issues rather than obvious test failures. Related concepts include Layered Architecture, Onion Architecture, Clean Architecture.