The West Market of Chang’an had more than two hundred shops — silk merchants, blacksmiths, mirror polishers, tea sellers — each running its own trade. Shops needed to exchange goods constantly: the silk shop needed the blacksmith’s clasps, the blacksmith needed the polisher’s sand, the polisher needed the tea shop’s water. In the old days, each owner walked the delivery over personally, collected payment, and haggled face to face.

Then three things went wrong.

First: a silk shop clerk delivered a shipment to the blacksmith, who swore he never received it. Did the clerk lose it on the road, or was the blacksmith lying? Nobody could say.

Second: the mirror polisher moved from the east end of the street to the west. Three shop owners spent two days figuring out the new address, missing several deals in the meantime.

Third: someone impersonated a silk shop clerk and picked up a batch of goods from the blacksmith. The blacksmith had never checked the visitor’s waist-token; the goods were gone.

The Market Prefect thought it over and issued an order: from today, a market clerk would stand at every shop’s door. Every piece of goods entering or leaving the shop — whether sent or received — must pass through that person’s hands.

The owners were unhappy at first. “I’ve been delivering my own goods for ten years — why do I need someone getting in my way at my own door?”

But the clerk’s work silenced them quickly.

Before a delivery boy left, the clerk at the door stamped the manifest: what was sent, to whom, at what hour and minute. At the blacksmith’s door, the receiving clerk checked the waist-token, matched the manifest, and confirmed the visitor really was sent by the silk shop and the goods matched. Both sides had records. No more disputes.

The polisher moved? The owner didn’t need to worry. The clerk checked the new address at the Prefect’s office and routed the next delivery there automatically. The owner didn’t even know the polisher had moved.

An impostor? The clerk checked the token. Anyone without one was turned away — they couldn’t even reach the shop door.

Better still: the Prefect could issue a decree — “The blacksmith’s output is too high this month; only ten items may leave per quarter-hour.” The clerk enforced it; the blacksmith changed nothing about how he ran his shop. And when the blacksmith’s forge caught fire, the clerk shut the door, and delivery boys heading that way were turned back automatically, spared from the blaze.

Later, a new owner moved into the West Market. He simply opened his shop. The next morning, a clerk was already standing at his door — identical to the ones at every other shop. He had filed no application, filled out no forms.

— By now you have probably recognized it: this is not a story about Tang Dynasty commerce. Each shop is a Pod, the clerk at the door is a sidecar proxy (usually Envoy), the Prefect’s office is the control plane (Istio’s istiod), “all goods must pass through the clerk” is the iptables rules hijacking all traffic in and out of the Pod, and the new owner who filed nothing yet found a clerk at his door is sidecar injection — a mutating admission webhook that automatically injects an Envoy container into every new Pod. This is the story of the service mesh data path.

What it is

The core idea of a service mesh is minimal: place a transparent proxy (sidecar) next to every application Pod, and route all network traffic in and out of the application through it. The application is completely unaware the proxy exists.

The implementation has two layers:

Data plane: the Envoy sidecar in every Pod. It does four things:

1. Traffic interception: when the Pod starts, an init container uses iptables (or eBPF) to redirect all outbound and inbound TCP traffic to Envoy’s listener port. The application thinks it’s connecting directly; it isn’t.
2. Service discovery: Envoy gets the endpoint list for every service from the control plane (EDS) and does its own load balancing. If the target Pod moves to another node, Envoy updates the route transparently.
3. mTLS: sidecars automatically establish mutual TLS between each other — no code changes in the application. Certificates are issued and rotated by the control plane.
4. Observability: latency, error rate, and request volume for every hop are reported automatically — because traffic always passes through Envoy, you get 100% sampling without instrumenting a single line.

Control plane: Istio’s istiod. It translates high-level policies — Kubernetes Services, VirtualServices, DestinationRules — into Envoy’s xDS configuration and pushes it to every sidecar. The Prefect issues decrees; the clerks enforce them.

The most common injection method is a mutating admission webhook: label a namespace with istio-injection=enabled, and every Pod created in that namespace is automatically injected with an Envoy sidecar container and an iptables init container. The new owner filed nothing; a clerk appeared at his door.

Why it matters

The mesh solves cross-cutting concern offloading: retries, timeouts, rate limiting, circuit breaking, mTLS, canary releases, traffic mirroring — if you implement these in every service’s business code, you must reimplement them in every language and every framework, and upgrading means redeploying every service. Push them down to the infrastructure layer (the sidecar) and every service gets them for free; upgrading means rolling restart of sidecars only.

The cost is not zero. Every hop adds two userspace proxy traversals (source sidecar → destination sidecar), adding roughly 1–3ms of latency. Each Envoy instance consumes 50–100MB of memory. For latency-sensitive workloads or clusters with very many Pods, the arithmetic matters.

The emerging trend is ambient mesh (Istio ambient mode): a per-node ztunnel replaces the per-Pod sidecar, handling mTLS at the node level, while L7 policies are applied on demand through a waypoint proxy. The principle is unchanged — traffic must still pass through a proxy — but the proxy moves from “one person at every shop door” to “one checkpoint on every street.”

Metaphor mapping

• Two hundred shops in the West Market — Pods in a Kubernetes cluster
• Owners delivering goods personally — direct service-to-service calls, no proxy
• The clerk at the door — sidecar proxy (Envoy)
• “All goods must pass through the clerk” — iptables/eBPF traffic interception
• Stamping manifests and keeping records — distributed tracing and observability
• Checking the waist-token — mTLS mutual authentication
• The Prefect’s office — control plane (istiod)
• The Prefect ordering rate limits — DestinationRule / rate-limiting policy
• Looking up the new address — service discovery (EDS endpoint update)
• Shutting the door when the forge catches fire — circuit breaking
• New owner finds a clerk already at his door — sidecar injection (mutating admission webhook)
• Replacing per-shop clerks with street checkpoints — ambient mesh / ztunnel node-level proxy