Why would a Spring Boot application use a message broker like Kafka or RabbitMQ instead of calling another service directly over HTTP? | Interview Question | TechyTalkWithDev

Spring Boot Interview Questions

254 Questions

153

Why would a Spring Boot application use a message broker like Kafka or RabbitMQ instead of calling another service directly over HTTP?

154

What is Spring Kafka, and how do you produce and consume messages with it?

155

What is the difference between Kafka's at-least-once, at-most-once, and exactly-once delivery semantics?

156

What is Spring AMQP / RabbitMQ integration, and how does it differ conceptually from Kafka?

157

What happens when message processing in a @KafkaListener or @RabbitListener method throws an exception?

Interview questions

Question 153 of 254

Free

Why would a Spring Boot application use a message broker like Kafka or RabbitMQ instead of calling another service directly over HTTP?

Messaging

Direct synchronous HTTP calls couple services tightly — the caller blocks until the callee responds, and if the callee is down, the call fails immediately. A message broker decouples producer and consumer in both time and availability: the producer publishes a message and moves on immediately, the broker durably holds it, and the consumer processes it whenever it's able to — enabling asynchronous processing, buffering against traffic spikes, and resilience to a temporarily unavailable consumer.

Intermediate5 min

AccentureCapgeminiCognizantOracleIBMAmazon

#Message Broker#Kafka#RabbitMQ

Why would a Spring Boot application use a message broker like Kafka or RabbitMQ instead of calling another service directly over HTTP?

Decoupling Comes With Its Own New Failure Modes

Trading synchronous coupling for asynchronous messaging doesn't eliminate complexity, it relocates it — you now need to reason about message ordering, at-least-once vs exactly-once delivery guarantees, consumer lag, and dead-letter handling for messages that repeatedly fail processing. Message-based architectures are a genuine trade-off, not a strictly superior default choice over direct calls.

HTTP: caller blocks, needs the callee up right now · Message broker: publish and move on, broker holds it until the consumer is ready