Physical Constraint Floor

A team is given a 150 ms end-to-end budget for a transaction whose authorising party sits on another continent. The speed of light in fibre, with real routing, gives roughly 60 to 80 ms one way between the US coasts and about 120 to 150 ms between London and Singapore. The budget was spent before any code was written, and six months of optimisation work cannot recover it.

The physical constraint floor is the sum of those irreducible terms: propagation delay, egress bandwidth that must be contracted, hardware with a procurement lead time, licence terms counted against physical cores, a regulator's data-residency boundary. They are not obstacles to engineer around; they are the subtraction you perform before deciding what is affordable.

Why it matters

Most capacity and latency failures are not failures of engineering. They are failures to identify which constraint binds first, followed by months of effort spent on a tier that was never the bottleneck. The pattern is consistent: the team scales the thing with an API in front of it, because that is the thing that can be scaled quickly, and the binding constraint sits behind a procurement process.

It also decides architecture rather than configuration. A synchronous cross-region commit at 70 ms each way is not a tuning problem: it means either accepting 140 ms on every write, or moving to an asynchronous model with a stated recovery point objective. The floor does not tell you what to build; it tells you which designs are not available.

Implementation patterns

• Write the floor down before the design, as a subtraction. Total budget minus propagation, minus handshakes you cannot avoid, minus the third party's own p99. What remains is what your services may spend.
• Attach a lead time to every capacity constraint. Compute and managed throughput: minutes. Contracted bandwidth, vendor quota increases needing a human, third-party rate limits: 10 to 40 days. Physical capacity in a named region, specialised hardware, core-counted licences: months.
• Record the source and the expiry. A vendor rate limit is a fact about a contract, not about the world, and it changes when the contract does. A constraint with no recorded source becomes permanent folklore.
• Design admission control on the floor, not on the elastic tier. If relay bandwidth is the limit, cap concurrent sessions per region and reject at the door; degrading everyone already inside is worse than refusing one new entrant.
• Convert the floor into a product decision where you can. Move the work closer to the user, make the operation asynchronous, or pre-compute. Each changes which floor applies rather than removing one.

Industry example

Zoom's daily meeting participants rose from roughly 10 million in December 2019 to about 300 million by April 2020, as the company reported publicly. The elastic part of that problem — the services handling meeting joins — is buyable in minutes. The part that is not is relay capacity and egress bandwidth in the regions where participants actually sit, because media relaying consumes bandwidth per participant per second for the duration of a call, and transit capacity at a facility is a contract with weeks of lead time.

The same asymmetry appears in cross-region database design. Google's Spanner paper (2012) documents TrueTime and commit-wait precisely because the cost of coordinating across geography is bounded below by the time signals take to travel, so the system is designed to spend that time deliberately rather than to pretend it is not there.

Failure scenarios

• Scaling the wrong tier. Autoscaling the stateless front end when egress bandwidth binds: the dashboards improve and the user experience degrades, because bandwidth exhaustion shows up as packet loss, not as errors.
• A latency target that was never achievable. Agreed with a customer, measured end to end, and smaller than the propagation delay to the dependency it needs.
• A licence bill arriving after the fact, because the metric counts every physical core in the cluster the virtual machine may run on rather than the vCPUs assigned.
• Quota discovered during the incident. A third-party rate limit found at peak, where the fix needs a human at the vendor and the vendor's queue is 3 days deep.
• A folklore constraint. A limit that was true of a contract cancelled two years ago, still shaping designs because nobody recorded its source.

Trade-offs

Identifying the floor early costs real investigation — reading contracts, measuring propagation, asking vendors for written limits — before any code exists, which feels like delay. The purchase is that the design space is drawn correctly the first time.

The opposite error is treating too much as a floor. A constraint asserted without a source is usually soft, and teams that cannot distinguish the two design around limits that a phone call would have removed. The discipline is a recorded source for every floor, so the soft ones can be challenged.

When not to use it

Do not run this analysis for a system comfortably inside every limit. A service at 200 requests a second with a 2-second budget on one continent has no binding physical floor, and a document enumerating propagation delays is wasted effort that makes the design look harder than it is.

It also does not apply when the dominant cost is the organisation rather than the machine. If lead time is 6 weeks because of handoffs and approvals, no amount of constraint analysis helps; the floor there is coordination, and that one is soft.

Interview question

Q: You are handed a 150 ms end-to-end latency target for a payment authorisation that must be confirmed by a network whose nearest endpoint is on another continent. Tell me what you do in the first week, and what you propose if the number cannot be met.

What a strong answer covers: measuring the irreducible terms first — propagation each way, the third party's own p99, mandatory handshakes — and presenting the remainder as the budget available to the team · refusing to accept the target before the subtraction, with the number as evidence · the design alternatives the floor permits: authorise asynchronously and confirm later, pre-authorise against a local risk decision with a documented exposure limit, or move the service to the continent that matters · what each alternative costs in money and in risk · the conversation with whoever set the 150 ms, framed as a choice between a slower confirmation and a different consistency model rather than as a failure to optimise.

Quick check

Quiz: Name three capacity constraints by lead time. — Compute and managed throughput in minutes; contracted bandwidth and vendor quota increases in 10 to 40 days; physical capacity in a named region, specialised hardware and core-counted licences in months.

Flashcard: Why does scaling the elastic tier sometimes make user experience worse? — Because it lets more load reach the constraint that actually binds; if that is bandwidth or relay capacity, the extra load arrives as packet loss and degradation rather than as errors, so the dashboards improve while users suffer.