What is Synchronous Communication in Microservices?

1. What is Synchronous Communication?

Synchronous communication is a communication method where one microservice sends a request to another microservice and waits for a response before continuing its work.

In simple terms:

Request → Wait → Response → Continue

Common technologies are:

• REST API using HTTP/HTTPS
• gRPC

Example

Suppose an Order Service needs to check whether a product is available.

Order Service
     │
     │ GET /api/inventory/101
     ▼
Inventory Service
     │
     │ Available = true
     ▼
Order Service
     │
     ▼
Continue Order

Until the Inventory Service responds, the Order Service is waiting for that result.

2. Why Do We Need Synchronous Communication?

Sometimes a microservice cannot continue without getting an immediate result from another service.

For example, before creating an order:

Order Service
      │
      ├──► Check Product
      │        ↓
      │     Response
      │
      ├──► Check Inventory
      │        ↓
      │     Response
      │
      └──► Continue Order

The Order Service needs those answers immediately.

Other examples:

• Get customer details
• Check product availability
• Validate a coupon
• Retrieve current pricing
• Perform an operation where the caller needs an immediate result

3. Purpose

The main purpose is to provide immediate request-response communication between services.

For example:

GET /api/products/101

Product Service responds:

{
  "id": 101,
  "name": "Laptop",
  "price": 75000
}

The calling service can immediately use this information.

4. ASP.NET Core Example

In ASP.NET Core, HttpClient is commonly used for HTTP-based service-to-service communication.

Order Service

public class ProductService
{
    private readonly HttpClient _httpClient;

    public ProductService(HttpClient httpClient)
    {
        _httpClient = httpClient;
    }

    public async Task<ProductDto?> GetProduct(int id)
    {
        return await _httpClient
            .GetFromJsonAsync<ProductDto>($"api/products/{id}");
    }
}

Register it:

builder.Services.AddHttpClient<ProductService>(client =>
{
    client.BaseAddress =
        new Uri("https://product-service/");
});

Here:

Order Service
     │
     │ HTTP Request
     ▼
Product Service
     │
     │ HTTP Response
     ▼
Order Service continues

The Order Service waits for the Product Service response.

5. Advantages

Simple to Understand

The request/response flow is straightforward.

Request → Response

Immediate Response

The caller receives the result immediately.

Easy to Implement

REST APIs and HttpClient make implementation straightforward in ASP.NET Core.

Easy to Test

Endpoints can be tested using tools such as Swagger, Postman, or automated integration tests.

Suitable for Real-Time Operations

Useful when the next operation depends on the result of another service.

6. Disadvantages

Service Dependency

If Service A depends on Service B:

Service A → Service B

and Service B is unavailable, Service A may also fail to complete its operation.

Network Latency

Every network call takes time.

For example:

Order
  ↓
Product
  ↓
Inventory
  ↓
Payment

Multiple sequential calls can significantly increase total response time.

Cascading Failures

A failure in one downstream service can affect several upstream services.

Order → Inventory → Payment
                     ❌

Without proper resilience handling, the entire operation may fail.

Tighter Runtime Coupling

The calling service depends on the receiving service being available and responding within an acceptable time.

7. How Do We Handle These Problems?

Production systems commonly use resilience techniques such as:

• Timeouts
• Retries for appropriate transient failures
• Circuit Breaker
• Fallbacks, where appropriate
• Load balancing
• Service discovery
• Health checks
• Distributed tracing

For example:

Order Service
     │
     │ HTTP Request
     ▼
Timeout / Retry / Circuit Breaker
     │
     ▼
Inventory Service

Retries should be used carefully, especially for operations that can cause side effects.

8. Synchronous vs Asynchronous

9. Key Points

• Synchronous communication follows a request-response model.
• The caller waits for the receiving service to respond.
• REST APIs and gRPC are common approaches.
• Use it when an immediate result is required.
• Too many synchronous service calls can increase latency and coupling.
• A downstream service failure can affect the calling service.
• Use timeouts, retries, circuit breakers, and observability to improve resilience.
• Avoid directly accessing another microservice's database; communicate through defined service contracts.

10. Interview Questions & Answers

Q1. What is synchronous communication in Microservices?

Answer:
Synchronous communication is when one microservice sends a request to another microservice and waits for its response before continuing.

Q2. What are common synchronous communication technologies?

Answer:
The most common approaches are REST APIs over HTTP/HTTPS and gRPC.

Q3. When should we use synchronous communication?

Answer:
Use it when the calling service requires an immediate response before it can continue processing.

Q4. What is the main disadvantage?

Answer:
It creates runtime dependency between services. If the downstream service is slow or unavailable, the calling service can also become slow or fail.

Q5. How do you make synchronous communication resilient?

Answer:
Use techniques such as timeouts, carefully configured retries, circuit breakers, load balancing, health checks, and distributed tracing.

Q6. Give a simple real-time example.

Answer:
An Order Service calling an Inventory Service to check stock before confirming an order is a common synchronous communication example.