← Back to glossary

Message Broker

messaging Intermediate

TL;DR

A message broker is middleware that receives, routes, and delivers messages between producers and consumers — decoupling services and enabling async communication at scale.

Explanation

Message brokers: Kafka (high-throughput log, replay), RabbitMQ (feature-rich routing, AMQP), Redis Streams (lightweight, Kafka-like), SQS/SNS (AWS managed). Core concepts: producer sends to broker, consumer reads from queue/topic, broker persists until acknowledged. Benefits: decoupling (producers don't know consumers), durability (messages persist), load levelling, retries, dead letter queues. Patterns: point-to-point queue (one consumer gets each message), pub/sub topic (all subscribers get each message). PHP: php-amqplib (RabbitMQ), rdkafka, aws-sdk (SQS), Redis Streams via Predis/PhpRedis.

Common Misconception

✗ Message brokers and job queues are the same — job queues (Laravel Queue, Symfony Messenger) are application-level abstractions that can use message brokers as a transport.

Why It Matters

Message brokers are the backbone of microservice communication — they enable services to scale independently and survive each other's failures.

Common Mistakes

Not acknowledging messages — broker redelivers indefinitely.
Ignoring message TTL — queue grows unboundedly on consumer failure.
Using message broker where a job queue suffices — adds operational complexity.

Code Examples

✗ Vulnerable

// Synchronous service calls — tight coupling:
$orderService->process($order);
$inventoryService->decrement($items); // Fails? Order partially processed

✓ Fixed

// Async via message broker:
$bus->dispatch(new OrderPlaced($order->id));
// OrderPlacedHandler runs asynchronously, retried on failure
// InventoryHandler subscribes separately, independently retried

References

↗ https://www.rabbitmq.com/tutorials/amqp-concepts.html