Service Mesh: The Network Layer for Your Microservices
A service mesh acts as a dedicated network layer for microservices, handling complex communication logic outside your application. It enables features like mTLS and canary releases.
Why it exists
As architectures moved from monoliths to microservices, the network became a new source of complexity. Developers were embedding networking logic like retries, timeouts, and encryption into every service, creating boilerplate and inconsistency. A service mesh was invented to extract this logic out of the application and into a dedicated, manageable infrastructure layer.
The mental model
Think of a service mesh as a transparent networking layer for your services, managed by a proxy that runs alongside each one. This proxy, called a sidecar, intercepts all traffic flowing between your microservices and applies rules you define. Your application code just makes simple network calls like 'http://user-service/', and the mesh transparently handles security, reliability, and routing.
How it works
A service mesh has two components: a data plane and a control plane. The data plane is the set of all sidecar proxies that sit next to your services. These proxies handle the actual traffic. The control plane is a central set of services that you interact with to configure the behavior of all the proxies. For example, you tell the control plane, 'send 5% of traffic to the new version of the payments service,' and it pushes that configuration out to the relevant proxies, which then execute the rule.
When to use it
Use a service mesh when you have many microservices and need uniform, cross-cutting features. It's ideal for enforcing security policies like mutual TLS (mTLS) across all services, gaining deep observability into traffic patterns (latency, error rates), implementing advanced deployment strategies like canary releases, and adding resilience with automatic retries and circuit breakers.
When not to use it
Avoid a service mesh for monolithic applications or systems with only a few services. The operational overhead of deploying and managing the control plane and sidecar proxies is substantial. If your team isn't struggling with the complexity of inter-service communication, a mesh is a solution in search of a problem. It also adds a small amount of latency to every network call due to the extra proxy hop.
One canonical example
A platform team wants to enforce that all communication between microservices is encrypted, without requiring dozens of application teams to implement TLS correctly. They deploy a service mesh like Istio or Linkerd. They configure the control plane to enforce mutual TLS (mTLS) by default. The mesh automatically provisions certificates for each service, and the sidecar proxies handle the TLS handshake and encryption. Application code continues to send plain HTTP traffic, completely unaware that it's being secured on the wire.
Interview question
A development team struggles with inconsistent retry logic and security policies across 50 microservices. How would a service mesh primarily address this challenge?
- a.It provides a framework for developers to standardize networking libraries within each microservice.
- b.It centralizes all external API requests, ensuring consistent policy enforcement at the edge.
- c.It transparently intercepts and manages inter-service communication, applying uniform policies via sidecar proxies.Correct
- d.It simplifies the deployment process by automatically configuring network routes for new services.
Why? this is the answer
A service mesh extracts networking logic from application code, using sidecar proxies to transparently enforce uniform policies like retries and security across all inter-service communication. Option B describes an API Gateway, which manages external traffic, not internal service-to-service communication. Option A describes the problem a service mesh solves, not its solution.
Just read this? Test yourself on what you have been reading.
Read the original → en.wikipedia.org
- #service mesh
- #microservices
- #networking
- #observability
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles