Design a service mesh for a large microservices platform with 200 services and 5,000 service instances. The mesh must provide: service-to-service authentication (mutual TLS), traffic management (canary deployments, circuit breaking, retries), observability (distributed tracing, metrics collection), and load balancing -- all without requiring application code changes. The platform handles 1 million inter-service requests per second.
In your 90-second answer, cover: - The sidecar proxy pattern: how it intercepts traffic transparently - Control plane vs. data plane architecture - How mutual TLS is managed (certificate issuance, rotation) across 5,000 instances - Traffic management: canary deployments and circuit breaking - Observability: how the mesh collects distributed traces and metrics without app changes
Constraints: the sidecar must add less than 1ms of latency per hop. Certificate rotation must happen without service restarts or downtime.
How to approach it
- Hint 1
The sidecar proxy (Envoy) is deployed alongside every service instance. It intercepts all inbound and outbound traffic via iptables rules or network namespace configuration -- the application thinks it is talking directly to other services.
- Hint 2
The control plane (like Istio's istiod) is the brain. It pushes configuration (routing rules, policies, certificates) to all sidecar proxies. The data plane (all the sidecars) handles actual traffic. This separation is key to understanding the architecture.
- Hint 3
For mTLS certificate management, the control plane acts as a Certificate Authority. It issues short-lived certificates (e.g., 24-hour TTL) to each sidecar and rotates them automatically before expiry -- no human intervention or service restarts needed.
Ready to answer it out loud?
Record your answer in 1:30 and Preptile scores it 1–10 with specifics — what landed, what you skipped, and what to say next time.
Practising needs an invite code. Join the waitlist and we’ll send you one.