Design a Service Mesh

Requirements

• •Automatically inject sidecar proxies into every service pod without application changes
• •Enforce mutual TLS for all intra-mesh communication with automatic certificate rotation
• •Implement service discovery: sidecars discover upstream endpoints dynamically via the control plane
• •Provide traffic shaping: canary deployments (weight-based routing), retries, and timeouts configurable per route
• •Expose per-service observability: request latency, error rate, and throughput from the data plane

Non-Functional Requirements

• •Sidecar overhead: < 1ms added latency per service-to-service call
• •mTLS certificate rotation: zero-downtime, every 24 hours
• •Control plane serves 1,000 sidecar proxies with < 5 second config propagation
• •Data plane handles 1 million requests/second across all services

Constraints

• •Target environment: Kubernetes cluster with 500+ microservices
• •All east-west (service-to-service) traffic must be encrypted via mTLS
• •Applications should not require code changes to adopt the mesh

Evaluation Criteria