Synchronous vs asynchronous communication in Microservices - Design Approaches Compared

Design: Microservices Communication System

Design focuses on communication patterns between microservices including request flow, components, and data handling. Out of scope are detailed service business logic and UI design.

Functional Requirements

FR1: Enable services to communicate with each other to fulfill user requests

FR2: Support both synchronous and asynchronous communication methods

FR3: Ensure reliable message delivery and error handling

FR4: Allow scaling to handle 10,000 concurrent requests

FR5: Provide low latency for synchronous calls (p99 < 200ms)

FR6: Support eventual consistency for asynchronous operations

Non-Functional Requirements

NFR1: System must maintain 99.9% uptime

NFR2: Latency for synchronous calls must be under 200ms for 99th percentile

NFR3: Asynchronous communication should handle message retries and dead-letter queues

NFR4: Services may be deployed independently and scaled horizontally

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

API Gateway or Service Mesh for routing synchronous calls

Message Broker (e.g., Kafka, RabbitMQ) for asynchronous messaging

Service Registry for service discovery

Load Balancers for scaling services

Monitoring and Logging tools for tracing communication

Design Patterns

Request-Response pattern for synchronous communication

Event-Driven Architecture for asynchronous communication

Circuit Breaker pattern to handle failures in synchronous calls

Message Queues with retry and dead-letter handling

Publish-Subscribe model for event distribution

Reference Architecture

Client
  |
  v
API Gateway / Service Mesh
  |
  +-----------------------------+
  |                             |
Sync Service A <----> Sync Service B
  |
  +-----------------------------+
  |
Message Broker (Kafka/RabbitMQ)
  |
Async Service A --> Async Service B

Components

API Gateway / Service Mesh

Envoy, Istio, or NGINX

Routes synchronous requests between services and clients, handles load balancing and security

Message Broker

Apache Kafka or RabbitMQ

Manages asynchronous message delivery, supports retries and dead-letter queues

Service Registry

Consul or Eureka

Keeps track of available services and their network locations

Microservices

Docker containers running services in any language

Business logic units communicating synchronously or asynchronously

Monitoring and Logging

Prometheus, Grafana, ELK Stack

Tracks system health, latency, errors, and message flows

Request Flow

1. Client sends synchronous request to API Gateway.

2. API Gateway routes request to Service A synchronously.

3. Service A processes request and may call Service B synchronously via API Gateway or Service Mesh.

4. For asynchronous operations, Service A publishes event/message to Message Broker.

5. Message Broker stores and delivers message to interested Async Service B.

6. Async Service B processes message independently and updates its state.

7. Failures in synchronous calls trigger retries or circuit breakers.

8. Failures in asynchronous processing trigger message retries or dead-letter queue handling.

Database Schema

Entities: Service, Message, Event Relationships: - Service (1) to Message (N): Services produce or consume multiple messages - Message (N) to Event (1): Messages represent events with payload and metadata - Service (N) to Service (N): Services communicate synchronously or asynchronously Attributes: - Service: service_id, name, endpoint - Message: message_id, type, payload, status, timestamp - Event: event_id, event_type, data, created_at

Scaling Discussion

Bottlenecks

API Gateway becomes a bottleneck under high synchronous request load

Message Broker storage and throughput limits for asynchronous messages

Service discovery delays or stale information

Network latency affecting synchronous calls

Failure handling causing cascading failures

Solutions

Scale API Gateway horizontally with load balancers and use service mesh for direct service-to-service calls

Partition and replicate Message Broker topics/queues, use high-throughput brokers like Kafka

Use distributed, highly available service registries with health checks

Optimize network paths, use caching and retries with circuit breakers

Implement bulkheads and fallback mechanisms to isolate failures

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and failure handling, 5 minutes summarizing.

Explain difference between synchronous and asynchronous communication with examples

Describe components needed for each communication type and why

Discuss trade-offs in latency, reliability, and complexity

Show understanding of failure scenarios and mitigation patterns

Highlight scalability strategies and monitoring importance

Practice

1. Which statement best describes synchronous communication in microservices?

easy

A. The caller waits for the response before continuing.

B. The caller sends a request and continues without waiting.

C. The services communicate only through message queues.

D. The services never exchange data directly.

Solution

1. Step 1: Understand synchronous communication

   Synchronous communication means the caller waits for the response before moving on.

2. Step 2: Compare options

   The caller waits for the response before continuing. matches this definition exactly, while others describe asynchronous or unrelated concepts.

3. Final Answer:

   The caller waits for the response before continuing. -> Option A

4. Quick Check:

   Synchronous = Wait for reply [OK]

Hint: Synchronous means wait for reply before next step [OK]

Common Mistakes:

• Confusing synchronous with asynchronous communication
• Thinking synchronous means no waiting
• Assuming message queues are always synchronous

2. Which of the following is the correct way to describe asynchronous communication in microservices?

easy

A. The caller blocks until the response is received.

B. The caller uses a direct function call to get the result.

C. The services must be on the same server.

D. The caller sends a request and processes the response later.

Solution

1. Step 1: Define asynchronous communication

   Asynchronous means the caller sends a request and does not wait; it handles the response later.

2. Step 2: Evaluate options

   The caller sends a request and processes the response later. correctly describes this behavior. Options A and D describe synchronous calls, and C is unrelated.

3. Final Answer:

   The caller sends a request and processes the response later. -> Option D

4. Quick Check:

   Asynchronous = Send and continue [OK]

Hint: Async means send request, handle reply later [OK]

Common Mistakes:

• Mixing up blocking and non-blocking calls
• Assuming async requires same server
• Thinking async means no response

3. Consider this pseudocode for a microservice call:

response = callServiceSync(request)
print("Done")

What will be the output order?

medium

A. "Done" prints before the service responds.

B. "Done" prints after the service responds.

C. The code throws an error because of missing callback.

D. The code runs asynchronously without waiting.

Solution

1. Step 1: Analyze synchronous call behavior

   The function callServiceSync waits for the service response before returning.

2. Step 2: Determine print timing

   Since the call blocks, "Done" prints only after the response is received.

3. Final Answer:

   "Done" prints after the service responds. -> Option B

4. Quick Check:

   Synchronous call blocks, then prints [OK]

Hint: Sync calls block; print happens after response [OK]

Common Mistakes:

• Assuming print runs before response
• Confusing sync with async calls
• Expecting errors due to missing async syntax

4. A developer wrote this asynchronous call:

sendRequestAsync(request)
print("Request sent")
waitForResponse()

But the system blocks until the response arrives. What is the likely mistake?

medium

A. print statement should be after waitForResponse().

B. sendRequestAsync() is actually synchronous.

C. Calling waitForResponse() immediately blocks the flow.

D. The request object is malformed.

Solution

1. Step 1: Understand asynchronous call flow

   sendRequestAsync should not block, but waitForResponse() forces waiting.

2. Step 2: Identify blocking cause

   Calling waitForResponse() immediately after sends blocks the flow, negating async benefits.

3. Final Answer:

   Calling waitForResponse() immediately blocks the flow. -> Option C

4. Quick Check:

   Immediate wait blocks async [OK]

Hint: Waiting right after async call blocks it [OK]

Common Mistakes:

• Assuming async call is sync
• Misplacing print statement
• Blaming request format instead of flow

5. You design a microservice system where user requests must get immediate confirmation, but heavy processing can be delayed. Which communication pattern fits best?

hard

A. Use synchronous communication for confirmation and asynchronous for processing.

B. Use only synchronous communication for all tasks.

C. Use only asynchronous communication for all tasks.

D. Use synchronous communication for processing and asynchronous for confirmation.

Solution

1. Step 1: Analyze requirements

   Immediate confirmation requires waiting for a quick response (synchronous).

2. Step 2: Handle heavy processing

   Heavy tasks can be done later without blocking user, so asynchronous fits.

3. Step 3: Match communication patterns

   Combining synchronous for confirmation and asynchronous for processing meets both needs efficiently.

4. Final Answer:

   Use synchronous communication for confirmation and asynchronous for processing. -> Option A

5. Quick Check:

   Immediate reply = sync, heavy work = async [OK]

Hint: Immediate reply sync, heavy work async combo [OK]

Common Mistakes:

• Using only sync causes delays
• Using only async delays confirmation
• Reversing sync and async roles