Why inter-service communication defines architecture in Microservices - Design It to Understand It

Design: Microservices Architecture Communication

Focus on communication mechanisms between microservices and how they shape system design. Out of scope are internal service implementations and UI design.

Functional Requirements

FR1: Enable multiple independent services to communicate effectively

FR2: Support synchronous and asynchronous communication patterns

FR3: Ensure reliable message delivery between services

FR4: Handle service discovery and load balancing

FR5: Maintain data consistency across services

FR6: Support scalability and fault tolerance

Non-Functional Requirements

NFR1: Latency for synchronous calls should be under 200ms p99

NFR2: System should handle 10,000 concurrent service-to-service calls

NFR3: Availability target of 99.9% uptime for communication channels

NFR4: Communication must be secure and authenticated

NFR5: Services may be deployed in different data centers or cloud regions

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

API Gateway or Service Mesh

Message Broker (e.g., Kafka, RabbitMQ)

Service Registry and Discovery

Load Balancer

Circuit Breaker and Retry Mechanisms

Authentication and Authorization components

Design Patterns

Request-Response (Synchronous) communication

Event-Driven (Asynchronous) communication

Publish-Subscribe pattern

Saga pattern for distributed transactions

Circuit Breaker pattern

Bulkhead pattern

Reference Architecture

Client
  |
  v
API Gateway / Service Mesh
  |
  +-----------------------------+
  |                             |
Service A <--> Service B <--> Service C
  |            |               |
  v            v               v
Message Broker (Kafka/RabbitMQ)
  |
  v
Service D (Event Consumer)

Service Registry & Discovery used by all services

Authentication & Authorization layer integrated at API Gateway and services

Components

API Gateway / Service Mesh

Envoy, Istio, or NGINX

Routes requests, handles load balancing, security, and observability

Service Registry and Discovery

Consul, Eureka, or Kubernetes DNS

Allows services to find each other dynamically

Message Broker

Apache Kafka or RabbitMQ

Supports asynchronous event-driven communication and decouples services

Circuit Breaker

Resilience4j or Hystrix

Prevents cascading failures by stopping calls to failing services

Authentication and Authorization

OAuth 2.0, JWT tokens

Secures communication between services

Request Flow

1. Client sends request to API Gateway

2. API Gateway authenticates and routes request to target service

3. Service uses Service Registry to locate dependent services

4. For synchronous calls, service calls another service via API Gateway or direct HTTP/gRPC

5. For asynchronous calls, service publishes event to Message Broker

6. Other services subscribe to events from Message Broker and process asynchronously

7. Circuit Breaker monitors service health and prevents calls to unhealthy services

8. Services update state and respond back through API Gateway to client

Database Schema

Not applicable as focus is on communication; however, services maintain own databases to ensure loose coupling and data ownership.

Scaling Discussion

Bottlenecks

API Gateway becoming a single point of failure or bottleneck

Message Broker overload with high event volume

Service Registry latency causing service discovery delays

Network latency impacting synchronous calls

Failure propagation causing cascading failures

Solutions

Deploy multiple API Gateway instances with load balancing and failover

Partition and scale Message Broker clusters horizontally

Use caching and replication for Service Registry to reduce latency

Favor asynchronous communication to reduce latency impact

Implement Circuit Breaker and Bulkhead patterns to isolate failures

Interview Tips

Time: Spend 10 minutes understanding requirements and constraints, 20 minutes designing architecture and explaining communication patterns, 10 minutes discussing scaling and failure handling, 5 minutes for questions.

Explain difference between synchronous and asynchronous communication

Discuss how communication patterns affect latency and scalability

Highlight importance of service discovery and load balancing

Describe failure handling with Circuit Breaker and retries

Mention security considerations in inter-service communication

Show awareness of trade-offs between consistency and availability