Runtime Coupling Surface
also called Delivery Mechanism Coupling, Build-Time versus Runtime Coupling
Whether a shared capability reaches consumers by rebuild or by redeploying something beside them — the property that sets how fast a change to that capability can reach production.
Authentication, rate limiting and request tracing must behave identically across 60 services in four languages, and the rules change roughly monthly. The design question is not which capability to build but how a change to it travels: a library change travels when 60 teams rebuild and redeploy, a sidecar change travels when you roll out one artefact, and a gateway change travels instantly at the cost of a hop on every call.
That is the runtime coupling surface. It is a property of the delivery mechanism rather than of the capability, and it determines patch latency, the number of implementations you maintain, and which failure domains you have created.
Why it matters
Patch latency is an operational number nobody writes down until it is urgent. With a library, the estate's patch latency is the slowest of 60 release cycles, typically weeks, with a tail of services that have no active owner. With a sidecar it is a staged fleet rollout measured in hours — 4 to 8 hours for a cautious cohort schedule against 6 to 11 weeks for 60 rebuilds. The capability is identical; only the coupling differs.
The second consequence is implementation count. Four languages means four library implementations to keep behaviourally identical, which is four chances to be subtly wrong about token validation. A proxy beside the service is one implementation for all four.
Implementation patterns
- Sidecar for behaviour that changes often across heterogeneous runtimes. This is what Lyft built Envoy for, open-sourced in 2016: retries, timeouts, service discovery and observability moved out of polyglot application code so they could change without touching services.
- Gateway at the edge, where traffic enters once and the detour is already paid. Many estates run both: a gateway north-south, sidecars east-west.
- Narrow libraries for stable, logic-only concerns, split by reason to change so a consumer taking a security fix does not also inherit a logging change.
- Make the control plane statically stable. A node must start and serve from its last known good configuration when the control plane is unreachable, or you have converted a configuration outage into a traffic outage.
- Stage rollouts by consumer cohort, not by node. A bad proxy release is a fleet-wide event, so the first cohort should be services whose failure you can tolerate.
- Measure patch latency explicitly: time from fix available to the last instance running it, reported from the running processes rather than from merged pull requests.
Industry example
Envoy's origin at Lyft is the documented case for the sidecar form, and the pattern has since become the basis of service meshes. The counter-example is equally instructive: organisations that adopted a mesh for a handful of cross-cutting behaviours across a small estate acquired a control plane, an upgrade treadmill and a novel failure mode in exchange for drift that a code review would have prevented. The pattern is not a maturity level, and the same reasoning that justifies it at 60 polyglot services rejects it at eight.
Failure scenarios
- An urgent fix that takes a quarter, because the delivery mechanism is a library and the long tail of consumers is unowned.
- A control-plane outage becoming a traffic outage, when sidecars cannot serve without fresh configuration.
- A bad proxy release hitting the whole fleet, because the sidecar is deployed uniformly rather than in cohorts.
- Latency budget consumed by hops, where a millisecond per hop is a large share of a few-millisecond budget.
- Silent behavioural drift between language implementations of a library, found only when a conformance suite is written after the fact.
- A gateway on the internal path becoming a single point of failure whose capacity scales with total internal traffic rather than ingress.
Trade-offs
| If this is true | Choose | Because |
|---|---|---|
| Rules change monthly across several languages | Sidecar | One implementation and one rollout per change |
| Rules change yearly, one language | Library | No control plane and no per-hop cost |
| Traffic is nearly all north-south | Gateway | The hop is already on the path |
| Under about ten services | Library or in-service | A mesh costs more than the drift it prevents |
| Per-request budget is a few milliseconds | Library | A millisecond per hop is a large share |
When not to use it
Do not move a capability out of a library on this reasoning alone. The decision rule is change frequency and urgency: a money type, a date utility or a domain primitive belongs in a library forever, because there is no runtime failure mode and nothing about it needs to propagate quickly. And in a small single-language estate, per-service implementations with a shared conformance test are honest, cheap and good enough, which is the answer a staff engineer should be willing to give when the fashionable one is a mesh.
Interview question
Q: Your organisation has 40 services in two languages. Authentication logic lives in a shared library and a critical fix took eleven weeks to reach every service last quarter. The platform team proposes a service mesh. Evaluate the proposal and tell me what you would do instead, if anything.
What a strong answer covers: naming patch latency as the actual problem and measuring it from running instances · separating the question of coupling mode from the question of adopting a mesh, since a sidecar for one capability is not a mesh · the control-plane availability requirement and static stability as a precondition · the alternative of splitting the library by reason to change plus automated dependency updates, which may be sufficient at 40 services in two languages · the per-hop latency and operational costs stated in numbers · and a decision stated as a rule with a threshold rather than a preference.
Quick check
Quiz: Why does a shared library make an estate's patch latency equal to its slowest release cycle? — Because the fix is only live once each consumer has rebuilt and redeployed, so propagation is bounded by the last team to ship, not by the time to merge.
Flashcard: What must be true of a sidecar's control plane before you depend on it? — It must be statically stable: a node starts and serves from its last known good configuration when the control plane is unreachable, so a configuration outage does not stop traffic.