Microservices How Services Communicate

Microservices run as separate programs. They cannot call functions inside each other the way code in the same application does. Instead, they send messages over a network. Understanding the communication options helps you pick the right tool for each situation.

Two Main Communication Styles

Synchronous Communication

Service A sends a request and waits for Service B to reply before continuing. This is like making a phone call — you speak, you wait, the other person responds.

Asynchronous Communication

Service A sends a message and moves on immediately without waiting. Service B picks up the message and processes it in its own time. This is like sending an email — you send it and continue your day. The reply arrives later.

Diagram: Sync vs Async

SYNCHRONOUS (HTTP/REST)
=======================
[Order Service] ---HTTP Request---> [Payment Service]
[Order Service] <--HTTP Response--- [Payment Service]
     WAITS here until payment responds


ASYNCHRONOUS (Message Queue)
=============================
[Order Service] ---Message---> [Message Queue]
[Order Service] continues immediately

Later:
[Message Queue] ---Message---> [Email Service]
[Email Service] sends confirmation email

HTTP and REST APIs

REST (Representational State Transfer) is the most common way services talk to each other synchronously. A service exposes a URL — called an endpoint — and other services call it using standard HTTP methods.

• GET — read data (fetch order details).
• POST — create something new (place an order).
• PUT — update something (change delivery address).
• DELETE — remove something (cancel an order).

Services exchange data in JSON format — a text format both humans and machines can read easily.

Example: Order Service calls Payment Service

Request:
POST https://payment-service/charge
{
  "order_id": "ORD-9912",
  "amount": 29.99,
  "currency": "USD",
  "card_token": "tok_abc123"
}

Response:
{
  "status": "success",
  "transaction_id": "TXN-55210"
}

gRPC

gRPC is a faster alternative to REST for internal service communication. Instead of text-based JSON, gRPC sends binary data. This makes it faster and uses less bandwidth.

Think of REST as writing a letter (text, readable, slightly slow) and gRPC as Morse code (compressed, fast, needs a decoder). Both carry the same message — gRPC just does it faster.

gRPC works best when services exchange large volumes of data or need very low response times — for example, between a search service and a ranking service in a recommendation engine.

Message Queues

A message queue sits between two services. One service puts a message in the queue. The other service reads messages from the queue whenever it is ready. The sender never waits for the receiver.

COURIER COMPANY ANALOGY
========================
[Sender / Order Service]
         |
         v
  [Sorting Warehouse]   <-- This is the Message Queue
         |
         v
[Receiver / Email Service]

The sender drops the parcel and goes home.
The warehouse holds it until the delivery team picks it up.

Popular message queues include RabbitMQ and Apache Kafka. Kafka is especially powerful because it stores messages even after they are read, letting multiple services consume the same message.

When to Use Which

Use Synchronous (REST or gRPC) when:

• You need an immediate answer before continuing.
• Example: Checking if a payment was successful before confirming an order.

Use Asynchronous (Message Queue) when:

• The result is not needed immediately.
• Example: Sending a welcome email after a user registers — the user does not wait for the email to be sent before seeing the confirmation screen.
• You want the system to keep working even if the receiving service is temporarily offline.

Service-to-Service Trust and Contracts

When Service A calls Service B, both sides agree on a contract — the shape of the request and response. This contract is called an API contract. Both teams document it and agree not to change it without informing the other team.

Breaking a contract is like a water company suddenly changing the size of water pipes without telling anyone. Every home connected to the old pipe size loses water.

A Complete Communication Flow

USER clicks "Place Order"
         |
         v
   [Order Service] --> REST call --> [Inventory Service] (check stock)
         |
         v
   [Order Service] --> REST call --> [Payment Service] (charge card)
         |
         v
   [Order Service] --> Message Queue --> [Email Service] (send receipt)
                                    --> [Analytics Service] (log order)

Sync calls return results immediately.
Async messages are processed after the order is confirmed.

This combination — synchronous calls for critical steps, asynchronous messages for background tasks — is one of the most common patterns in production microservices systems.