A platform runs 2000 pods across 300 services and is about to put a sidecar proxy in every pod. Roughly what does the fleet cost in memory and control-plane work before a single request is served, and which number grows fastest as the platform doubles?

The assumptions, stated

A sidecar proxy that knows about every service in the mesh holds the routing table, endpoint list and certificates for all of them. In the field, a proxy configured with a few hundred services and a few thousand endpoints sits in the range of 50 to 150 MB of resident memory, and idles at roughly 0.05 to 0.2 vCPU with real per-request CPU on top. Treat those as orders of magnitude, not vendor numbers.

The arithmetic

• Memory: 2000 proxies at 100 MB is 200 GB of RAM bought purely to run proxies. On 32 GB nodes that is about six nodes' worth of memory, and it is charged whether traffic is flowing or not.
• CPU: 2000 at 0.1 vCPU idle is 200 vCPU, again before traffic.
• Latency: two extra hops per call, each parsing and re-emitting the request. Budget 0.5 to 2 ms added at p50 and more at p99, because the proxy is another queue that can sit behind a garbage collection pause or a config reload.
• Control plane: here is the term that matters. The control plane must push configuration to every proxy that could talk to a changed service. With naive scoping, one deployment that changes endpoints fans out to all 2000 proxies. The work is proportional to proxies x services, so doubling the platform quadruples the push volume.

The number, and which assumption dominates

Around 200 GB and 200 vCPU standing cost, and a control plane whose work rises with the square of platform growth. The error in the memory figure is dominated by how much of the registry each proxy is given. Scoping a proxy to only the services it actually calls cuts its memory several-fold and cuts push fan-out by the same factor. That single configuration decision moves the estimate more than any tuning of the proxy itself.

What the number rules in and out

At 2000 pods the standing cost is real but affordable, and uniform mTLS, retries and telemetry across 300 services is worth 200 GB. At 20,000 pods, the control plane becomes the thing you operate, and the architecture shifts: scope configuration per workload, or move to a design where the L4 path is handled per node and only the workloads needing L7 policy get a proxy.

When this is over-engineering

For a platform of fewer than roughly 20 services, this whole budget buys little. Certificate rotation can be handled by the platform's own identity integration, retries and timeouts belong in the client library you already ship, and a mesh adds a second failure domain that pages a team you probably do not have. Adopt the mesh when the number of services makes per-service implementation of these concerns the larger cost, which is usually somewhere in the tens of services and always when more than one language is in play.

How you would know you got it wrong

Watch the p99 of the proxy's own processing time and the config convergence lag: the interval between a deployment and the last proxy acknowledging the new endpoints. When convergence lag exceeds the time between deployments, the mesh is permanently behind reality, and traffic is being routed from a stale view during every rollout.