How to Implement Microservices Communication in Node.js

Microservices communicate in two fundamental ways. Synchronous communication means one service calls another and waits for a response, typically using HTTP or gRPC. Asynchronous communication means one service publishes a message to a broker and does not wait for a response. Other services consume the message at their own pace. Choosing the right style for each interaction is critical for reliability and scalability.

Use the axios or got package to make HTTP requests from one service to another. Define the target service's base URL in an environment variable so it can be changed per environment. Wrap all inter-service HTTP calls in try-catch blocks and implement retry logic with exponential backoff for transient failures. Set appropriate timeout values so a slow downstream service does not hold your service's connections indefinitely.

When a downstream service is down, requests to it will all fail and time out. Without a circuit breaker, your service wastes resources on requests that will fail and the timeouts slow down your response time. Implement a circuit breaker using a library like opossum. The circuit opens after a threshold of failures, immediately rejecting requests to the failing service for a recovery period before trying again.

Install the amqplib package to connect to RabbitMQ. Create a connection and a channel. Declare a queue by name. To publish a message, call channel.sendToQueue with the queue name and the message as a Buffer. The publisher does not wait for the consumer to process the message, making this non-blocking and resilient to consumer downtime.

In the consumer service, create a connection and channel, declare the same queue, and call channel.consume with the queue name and a callback. The callback receives the message, processes it, and calls channel.ack to acknowledge successful processing. If processing fails, call channel.nack to reject the message so RabbitMQ can requeue it and retry later.

For events that multiple services need to react to, use a fanout or topic exchange in RabbitMQ instead of a direct queue. The publisher sends a message to the exchange without knowing which services will consume it. Each consumer service creates its own queue and binds it to the exchange. RabbitMQ delivers a copy of every message to every bound queue.

For high-volume event streaming scenarios, Apache Kafka is more appropriate than RabbitMQ. Install kafkajs and create a Kafka producer to publish events to a named topic. Create a Kafka consumer group that subscribes to the topic. Kafka persists messages to disk for a configurable retention period, allowing consumers to replay historical events and making it suitable for event sourcing architectures.

In a dynamic environment where service instances start and stop, hardcoding service URLs is impractical. Use a service discovery tool or platform feature. In Kubernetes, services are discoverable by their service name as DNS records within the cluster. In other environments, use Consul or etcd as a service registry where services register their location on startup and query for other services by name.