Message brokers let microservices communicate asynchronously by relaying messages between them, so services can interact without being directly connected or available at the same time.
Key Points: • A broker like Kafka or RabbitMQ receives messages from a producer and delivers them to one or more consumers, decoupling the sender from the receiver. • Producers don't need to know which services will consume a message, or whether they're online at the moment the message is sent. • Brokers handle queuing, routing, and reliable delivery, often including retry and dead-letter mechanisms for messages that fail to process. • This decoupling improves scalability, since consumers can be added or scaled independently without changing the producer. • It also improves resilience, since a temporarily unavailable consumer doesn't block the producer; the message just waits in the queue or topic until it's processed.
Example: When an order is placed, the Order service publishes an event to a message broker instead of calling the Notification and Analytics services directly; both consume the event independently, and if the Analytics service is temporarily down, its messages simply wait in the broker until it comes back online.
Interview Tip: A concise interview answer is:
"Message brokers act as an intermediary that decouples services in time: a producer publishes a message without needing to know who consumes it or whether they're currently available. That improves scalability, since I can add consumers independently, and resilience, since a broker like Kafka or RabbitMQ queues messages reliably until a consumer is ready to process them."