Design Service Mesh - System Design | WinJob

Problem Statement: Service Mesh Platform Design

Design a service mesh for east-west microservice traffic on Kubernetes: mutual TLS, L7 routing, retries, circuit breaking, and unified observability without rewriting every service in a shared library.

Interviewers expect you to separate the control plane (Istiod, Linkerd destination, AWS App Mesh controller) from the data plane (Envoy sidecars, Linkerd micro-proxies). A strong answer states who owns the mesh (platform/SRE), how teams onboard workloads, and measurable outcomes: p99 sidecar latency < 3ms, 100% mTLS for in-mesh calls, trace sampling that does not drown the backend.

Core story

Identity — SPIFFE/SPIRE or mesh CA issues short-lived certs per workload identity.
Traffic policy — VirtualService/HTTPRoute sets timeouts, retries, fault injection, traffic splits.
Telemetry — RED metrics, access logs, W3C trace propagation from sidecar without app changes.
Progressive adoption — namespace labels for injection, allowlists for legacy plaintext during migration.

Interview Focus

Quantify sidecar CPU/RAM and p99 latency tax before naming Istio or Linkerd
Explain mTLS identity (SPIFFE) and STRICT vs PERMISSIVE migration
Show bounded retries, timeouts, and outlier detection as overload protection
Describe Istiod HA, xDS propagation, and failure behavior when control plane degrades

javaOne Dark Pro

1 public final class MeshRetryPolicy {
2   public int maxAttempts(boolean idempotent) {
3     return idempotent ? 2 : 1;
4   }
5   public long perTryTimeoutMs() { return 20L; }
6 }

pythonOne Dark Pro

1 from dataclasses import dataclass
2  
3 @dataclass
4 class PeerTlsMode:
5     namespace: str
6     mode: str  # STRICT | PERMISSIVE
7  
8 def allows_plaintext(mode: str) -> bool:
9     return mode == "PERMISSIVE"

typescriptOne Dark Pro

1 interface VirtualRoute {
2   host: string;
3   subset: string;
4   weight: number;
5 }
6  
7 export function canaryWeights(stable: number, candidate: number): VirtualRoute[] {
8   const total = stable + candidate;
9   return [
10     { host: "payments", subset: "stable", weight: stable / total },
11     { host: "payments", subset: "canary", weight: candidate / total },
12   ];
13 }

How to open this one

The framing that lands for a service mesh is moving cross-cutting concerns — mTLS, retries, traffic shifting, observability — out of application code into a sidecar proxy controlled by a central control plane. Lead with the data-plane/control-plane split (Envoy sidecars enforcing policy pushed by the control plane) and the failure story that proves it: a control-plane outage must not break the data plane, so proxies keep their last-known config and keep serving. That shows you understand the mesh's value is uniform policy without touching app code.

Key Highlights

•Separate mesh control plane from sidecar data plane
•Budget sidecar CPU/RAM and p99 latency overhead explicitly
•STRICT mTLS in prod; PERMISSIVE only for bounded migration
•Bounded retries and outlier detection prevent retry storms

1	public final class MeshRetryPolicy {
2	public int maxAttempts(boolean idempotent) {
3	return idempotent ? 2 : 1;
4	}
5	public long perTryTimeoutMs() { return 20L; }
6	}

1	from dataclasses import dataclass
2
3	@dataclass
4	class PeerTlsMode:
5	namespace: str
6	mode: str # STRICT \| PERMISSIVE
7
8	def allows_plaintext(mode: str) -> bool:
9	return mode == "PERMISSIVE"

1	interface VirtualRoute {
2	host: string;
3	subset: string;
4	weight: number;
5	}
6
7	export function canaryWeights(stable: number, candidate: number): VirtualRoute[] {
8	const total = stable + candidate;
9	return [
10	{ host: "payments", subset: "stable", weight: stable / total },
11	{ host: "payments", subset: "canary", weight: candidate / total },
12	];
13	}

Problem Statement: Service Mesh Platform Design

Core story

Interview Focus

How to open this one

Key Highlights

Section Rescue Kit