What is a Message Broker?

In a system built around direct calls, every service that needs to notify another service has to know its address, be available at the same time, and handle its own retry logic if the receiver is down. A message broker removes that tight coupling: producers publish messages to the broker, often onto a named queue or topic, and move on, while consumers subscribe and process messages at their own pace. The broker takes on responsibility for durable storage until delivery, retry semantics, and fan-out to multiple consumers of the same message. Brokers commonly support different delivery patterns — point-to-point queues where one consumer processes each message, or publish-subscribe topics where every subscriber gets a copy — and typically offer guarantees around ordering, at-least-once or exactly-once delivery, and dead-letter handling for messages that repeatedly fail processing. Popular implementations include RabbitMQ, Apache Kafka, and cloud-managed options like AWS SQS and SNS. The main benefit is resilience and scalability: a spike in producer traffic doesn't require consumers to keep pace in real time, and a temporarily-down consumer doesn't lose messages, since the broker holds them until it recovers.