Service mesh concept in Microservices - Architecture Diagram

System Overview - Service mesh concept

A service mesh manages communication between microservices in a distributed system. It provides features like secure connections, traffic control, and observability without changing the microservices themselves.

Key requirements include reliable service-to-service communication, security, and easy monitoring.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
+-------------------+       +-------------------+
|  Service A        |<----->|  Service B        |
|  (with sidecar)   |       |  (with sidecar)   |
+-------------------+       +-------------------+
        |                           |
        v                           v
   Service Mesh Control Plane (manages sidecars, policies, telemetry)
        |
        v
   Monitoring & Logging System

Components

User

client

Initiates requests to the system

Load Balancer

load_balancer

Distributes incoming requests evenly to API Gateway instances

API Gateway

api_gateway

Entry point for client requests, routes to appropriate services

Service A

service

Business logic microservice with sidecar proxy

Service B

service

Another business logic microservice with sidecar proxy

Sidecar Proxy

proxy

Handles service-to-service communication, security, and telemetry for each service

Service Mesh Control Plane

control_plane

Manages configuration, policies, and telemetry collection for sidecars

Monitoring & Logging System

monitoring

Collects and displays metrics and logs from the mesh

Request Flow - 13 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Service A Sidecar Proxy

Service A Sidecar Proxy → Service A

Service A Sidecar Proxy → Service B Sidecar Proxy

Service B Sidecar Proxy → Service B

Service B Sidecar Proxy → Service A Sidecar Proxy

Service A → Service A Sidecar Proxy

Service A Sidecar Proxy → API Gateway

API Gateway → Load Balancer

Load Balancer → User

Sidecar Proxies → Service Mesh Control Plane

Service Mesh Control Plane → Monitoring & Logging System

Failure Scenario

Component Fails:Service Mesh Control Plane

Impact:Sidecar proxies cannot receive updated policies or configurations, but existing connections continue working. Telemetry collection pauses.

Mitigation:Sidecars cache last known config and continue operating. Control plane is deployed with replicas for high availability.

Architecture Quiz - 3 Questions

Which component manages communication policies between microservices?

A Service Mesh Control Plane

B API Gateway

C Load Balancer

D Monitoring & Logging System

Design Principle

This architecture shows how a service mesh uses sidecar proxies alongside microservices to manage secure, observable, and reliable communication without changing the services themselves. The control plane centralizes configuration and telemetry, enabling dynamic policy enforcement and monitoring.

Practice

1. What is the main purpose of a service mesh in microservices architecture?

easy

A. To write application business logic

B. To store data for microservices

C. To replace microservices with monolithic applications

D. To manage communication between microservices securely and reliably

Solution

1. Step 1: Understand the role of service mesh

   A service mesh handles how microservices talk to each other, focusing on communication.

2. Step 2: Identify what service mesh does not do

   It does not store data, replace microservices, or write business logic.

3. Final Answer:

   To manage communication between microservices securely and reliably -> Option D

4. Quick Check:

   Service mesh = communication management [OK]

Hint: Service mesh controls microservice communication, not data or logic [OK]

Common Mistakes:

• Confusing service mesh with data storage
• Thinking service mesh replaces microservices
• Assuming service mesh writes app code

2. Which of the following is a common tool used to implement a service mesh?

easy

A. Docker

B. Istio

C. Kubernetes

D. Git

Solution

1. Step 1: Recall popular service mesh tools

   Istio, Linkerd, and Consul are well-known service mesh tools.

2. Step 2: Differentiate from other tools

   Docker is for containers, Kubernetes for orchestration, Git for version control, not service mesh.

3. Final Answer:

   Istio -> Option B

4. Quick Check:

   Istio = service mesh tool [OK]

Hint: Istio is a popular service mesh tool, not Docker or Git [OK]

Common Mistakes:

• Choosing Docker or Kubernetes as service mesh
• Confusing version control tools with service mesh
• Mixing container tools with service mesh tools

3. Given a microservices setup with Istio service mesh, what happens when a service-to-service call fails due to network issues?

medium

A. Istio retries the call automatically based on configured policies

B. The call fails immediately without retries

C. Istio shuts down the service permanently

D. The service mesh ignores the failure and logs no information

Solution

1. Step 1: Understand Istio's retry feature

   Istio can automatically retry failed calls to improve reliability.

2. Step 2: Eliminate incorrect behaviors

   Istio does not shut down services or ignore failures silently; it logs and manages retries.

3. Final Answer:

   Istio retries the call automatically based on configured policies -> Option A

4. Quick Check:

   Istio retries failed calls = true [OK]

Hint: Istio retries failed calls automatically if configured [OK]

Common Mistakes:

• Assuming no retries happen on failure
• Thinking Istio shuts down services on failure
• Believing failures are ignored silently

4. You deployed a service mesh but notice that traffic between microservices is not encrypted. What is the most likely cause?

medium

A. The network cables are unplugged

B. The microservices are not running

C. Mutual TLS (mTLS) is not enabled in the service mesh configuration

D. The service mesh is not installed

Solution

1. Step 1: Check encryption settings in service mesh

   Service mesh uses mutual TLS (mTLS) to encrypt traffic between services.

2. Step 2: Identify why encryption might fail

   If mTLS is not enabled, traffic remains unencrypted despite service mesh presence.

3. Final Answer:

   Mutual TLS (mTLS) is not enabled in the service mesh configuration -> Option C

4. Quick Check:

   mTLS disabled = no encryption [OK]

Hint: Enable mTLS to encrypt service mesh traffic [OK]

Common Mistakes:

• Assuming services not running causes no encryption
• Thinking service mesh absence causes partial encryption
• Ignoring mTLS setting importance

5. You want to add observability to your microservices without changing their code. How does a service mesh help achieve this?

hard

A. By injecting sidecar proxies that monitor and report traffic metrics transparently

B. By rewriting the microservices code to add logging

C. By replacing microservices with a single monolithic app

D. By disabling network communication between services

Solution

1. Step 1: Understand sidecar proxy role in service mesh

   Service mesh injects sidecar proxies alongside microservices to handle communication and monitoring without code changes.

2. Step 2: Eliminate incorrect options

   Service mesh does not rewrite code, replace microservices, or disable communication.

3. Final Answer:

   By injecting sidecar proxies that monitor and report traffic metrics transparently -> Option A

4. Quick Check:

   Sidecar proxies add observability without code change [OK]

Hint: Sidecar proxies add monitoring without changing app code [OK]

Common Mistakes:

• Thinking code must be rewritten for observability
• Confusing service mesh with app replacement
• Assuming communication is disabled for observability