Node.js › Message Queues (RabbitMQ & Kafka)

When would you choose a message queue/broker (RabbitMQ or Kafka) over simply making direct HTTP calls between Node.js microservices?

Intermediate

Answer

Direct HTTP calls create tight temporal coupling -- both services must be available simultaneously, and the calling service blocks waiting for a response, with a failure in the downstream service directly propagating as a failure to the caller. A message broker decouples services in time (a consumer doesn't need to be running the instant a message is published; it'll process it whenever it comes back online) and in failure mode (a downstream service being temporarily down doesn't fail the publisher's operation, since the message simply waits in the queue), at the cost of added infrastructure and eventual (rather than immediate) consistency.

// Tightly coupled: caller blocks and fails if inventory-service is down
await fetch('http://inventory-service/reserve', { method: 'POST', body: JSON.stringify(order) });

// Decoupled: publish and move on; inventory-service processes whenever it's available
await channel.sendToQueue('inventory-reservations', Buffer.from(JSON.stringify(order)));

Real-world example An order-placement service publishes an 'OrderPlaced' event to a queue rather than directly calling the inventory service's API synchronously, meaning a temporary outage in the inventory service doesn't prevent customers from placing orders -- inventory reservation simply happens a few seconds later once that service recovers and processes the backlog.

Common follow-ups: What's the cost of the eventual consistency this decoupling introduces, and in what scenarios is that unacceptable (like needing an immediate inventory check before confirming an order)?;How would you combine synchronous calls for time-sensitive checks with asynchronous messaging for everything else in the same order flow?

Architecture & Design Patterns;Microservices Architecture with Node.js