Fallacy of Zero Latency¶

The design-time assumption that a remote call returns as fast as a local one, dropping the per-hop round-trip term L from the cost function, so that an operation making n network calls is budgeted as free when it actually costs at least n·L and compounds under sequential fan-out.

Version: v4 · 2026-09-19 · History · 3 corrections
Domain-specific #: 379
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomain: Distributed Systems Fallacies of Distributed Computing → Computer Science & Software Engineering

Core Idea¶

The Fallacy of Zero Latency is the design-time assumption that a remote call returns as fast as a local one — that network round-trip time is effectively zero and can be ignored in API design and performance estimation. Real networks add irreducible latency, invisible on localhost and under light-load testing. The structural error is in the cost function: when per-call latency L is treated as zero, an operation making n remote calls looks free, when it actually costs at least n·L and compounds under sequential fan-out.

How would you explain it like I'm…

Far Answers Aren't Instant

Asking a friend sitting right next to you a question is super quick. Asking someone far away takes a while for your question to get there and the answer to come back. The Fallacy of Zero Latency is building computer programs as if far-away answers come back instantly. If you ask fifty far-away questions one at a time, all that waiting adds up.

The No-Waiting Myth

When one computer asks another computer for something over a network, the answer takes time to travel back. That waiting time is called latency, and it grows the farther away the other computer is. The Fallacy of Zero Latency is designing programs as if that wait were zero. In testing on one computer it seems instant, but in the real world, asking for 50 things one at a time adds up to a long wait. The fix is to ask fewer times, for example by getting all 50 things in one request, or by asking several at once instead of one after another.

Round Trips Aren't Free

The Fallacy of Zero Latency is assuming a remote call over a network returns as fast as a local function call. Real round trips take time that software can't remove. A call to a nearby machine adds microseconds to milliseconds, crossing continents adds tens of milliseconds or more, and mobile links can take over a second. If a task makes n remote calls one after another, each taking time L, the delay grows by at least n times L. When many calls must all finish, the slowest one sets the pace. Common culprits include loading database rows one query at a time and fetching 50 list items with 50 separate requests. Fixes include batching, caching, and running unavoidable calls in parallel instead of in sequence.

The Fallacy of Zero Latency treats network round-trip time as effectively zero in API design, call-count budgeting, and performance estimation. Latency is physically irreducible by software: microseconds to low milliseconds within a rack, tens of milliseconds across datacenters or continents, over a hundred on the longest intercontinental routes, and sometimes beyond a second on lossy mobile or edge links. None of this shows up on localhost or in light-load testing, which is exactly when systems are designed. With per-call latency L and n sequential calls, completion time grows by at least n·L. Tail effects make it worse: when the slowest of n calls sets the total, the fraction of requests that miss the latency budget rises steeply with n. Abstractions that hide the local/remote distinction invite this, through ORM lazy loading (N+1 queries), synchronous microservice fan-out chains, and per-item detail fetches. Remedies include batch endpoints, eager loading, caching, prefetching, denormalization, and data locality. All of them serve one principle: minimize sequential round trips on the critical path, and parallelize the ones that remain.

Scope of Application¶

The fallacy lives within distributed computing — the subfields where a composed operation's cost function drops the per-hop round-trip term L, and the corrective toolkit is native.

Object-relational mapping / persistence layer — the home case: lazy-loading issues a query per row (the N+1 pattern).
Microservice fan-out and service mesh — a single request synchronously chaining ten downstream calls.
Client-API design — a list view calling a detail endpoint once per item.
Multi-region and cross-datacenter deployment — the cross-continent hop invisible at design time and dominant in production.

Clarity¶

Naming the fallacy makes a per-call cost visible that local-call abstractions are built to hide: transparent RPC and ORM lazy-loading erase the local/remote distinction, so L silently drops from the cost model. It sharpens the distinction between number of calls and cost of the operation, and locates the trap in development practice — the latency is invisible on localhost, exactly where systems are designed.

Manages Complexity¶

A scattered catalogue of pathologies collapses to one term in a single cost function: per-call latency L, wrongly set to zero, so n calls cost at least n·L. The disparate bugs resolve into one shape (too many sequential round trips on the critical path), and the whole corrective toolkit resolves into one principle: minimize sequential round trips, parallelize the unavoidable ones.

Abstract Reasoning¶

Carrying L > 0 licenses a diagnostic move (read the round-trip count behind slowness, using the localhost-versus-production gap), an interventionist move (cut or parallelize round trips, each corrective a prediction), a boundary-drawing move (when n·L is negligible, zero latency is a safe approximation), and a forward move (budget production latency at design time).

Knowledge Transfer¶

Within distributed computing the fallacy transfers as mechanism across the persistence layer, service mesh, client-API design, and multi-region deployment, sharing the n·L cost function and the corrective toolkit — one of the Fallacies of Distributed Computing. Beyond it the portable content is the Latency prime plus the cost-of-composition shape; transaction costs and cross-team hand-offs are the same shape, not the same mechanism, so the RPC-native corrective vocabulary stays home.

Relationships to Other Abstractions¶

Current abstraction Fallacy of Zero Latency Domain-specific

Parents (1) — outgoing typed relations

Fallacy of Zero Latency is a kind of Idealized-Substrate Fallacy Prime

The fallacy of zero latency is the idealized-substrate fallacy specialized to a network whose omitted friction is positive per-hop delay.

Hierarchy path (1) — routes to 1 parentless root

Fallacy of Zero Latency → is a kind of Idealized-Substrate Fallacy → presupposes Abstraction

Neighborhood in Abstraction Space¶

Fallacy of Zero Latency sits in a sparse region of the domain-specific corpus (60^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Distributed Systems Theorems & Fallacies (19 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25