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