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.

Core Idea¶

The Fallacy of Zero Latency is the design-time assumption that a remote call returns as quickly as a local one — that the round-trip time across a network is, for practical purposes, zero, and can therefore be ignored in API design, call-count budgeting, and system performance estimation. Real networks add latency that is irreducible by software: a call to a service in a neighboring rack adds microseconds to low milliseconds; a cross-datacenter call adds tens of milliseconds; a cross-continent call adds a hundred milliseconds or more; and in mobile or edge environments, lossy links and radio scheduling can push individual round trips past a second. None of this is visible on localhost, and none of it is visible in light-load integration testing, which is precisely when distributed systems are designed and instrumented. The fallacy is invisible at the scale where it forms and catastrophic at the scale where it matters.

The structural error is in the cost function that drives API design. When the per-call latency L is treated as zero, a composed operation that makes n remote calls is estimated to complete in time proportional to its local computation. When L is not zero, the actual expected completion time grows by at least n·L — and for synchronous fan-out, where calls are sequential, the latency compounds directly. With tail latency effects — where the slowest of n calls determines the total — the effective cost grows super-linearly with n. API surfaces that hide the local/remote distinction encourage exactly this pattern: ORM lazy-loading issues a separate database query for each row in a result set (the N+1 pattern); synchronous microservice fan-out chains tens of downstream calls behind a single user-facing request; a client fetching 50 items in a list calls the detail endpoint 50 times rather than once. In development these are undetectable; in production they are the dominant latency term.

The corrective requires making per-call latency an explicit variable in API design rather than a constant that equals zero. The toolkit — batch endpoints that retrieve multiple records in a single round trip, eager loading in ORM layers, caching to avoid remote calls for data that changes slowly, prefetching to pipeline latency behind computation, denormalization to reduce the call count needed to assemble a response, data locality to reduce the physical distance each call must traverse — is unified by a single principle: minimize the number of sequential round trips on the critical path of each user-visible operation, and where round trips are unavoidable, issue them in parallel rather than in series.

Structural Signature¶

Sig role-phrases:

the composed operation — a single user-facing action that triggers n remote calls to assemble its result
the irreducible per-hop latency — the round-trip time L > 0 a network adds (microseconds same-rack, tens of ms cross-datacenter, 100ms+ cross-continent), unfixable by software
the distinction-hiding API — transparent RPC, ORM lazy-loading, chatty interfaces that erase the local/remote boundary at the call site
the L=0 cost function — the design-time treatment of per-call latency as zero, so n calls look free
the development-environment mask — localhost and light-load testing suppress L, so the term is invisible exactly where systems are designed
the n·L compounding — actual cost grows by at least n·L, directly under sequential fan-out and super-linearly once tail latency lets the slowest of n set the total
the signature pathologies — N+1 queries, deep synchronous microservice fan-out, a list view calling a detail endpoint once per row, all one shape
the minimize-round-trips corrective — batch endpoints, eager loading, caching, prefetching, denormalization, data locality, and parallelizing the unavoidable hops
the n·L boundary — few calls, small L, or off-critical-path hops keep "remote ≈ local" safe; a clean local test does not certify the safe side
the substrate-bound limitation — the corrective vocabulary (batch, prefetch, denormalize) and RPC surface are computing-native; the latency prime plus the cost-of-composition shape is what travels

What It Is Not¶

Not a claim that the network is slow. The fallacy is not that latency is high, but that the per-call round-trip term L is dropped from the cost function — n remote calls treated as free because L is set to zero. Whether it bites is conditional on the product n·L against the operation's latency budget: few calls, small L, or hops off the user-visible critical path keep "remote ≈ local" a safe approximation. The error is the omitted term, not delay as such.
Not the same as transport cost. Latency is response time per round trip; it is distinct from the per-byte transport cost c its sibling fallacy names. A design can move tiny payloads (cheap c) yet still be latency-bound by issuing many sequential round trips (n·L), or move huge payloads cheaply in latency terms while running up egress charges. Conflating the two cost terms (L → 0 versus c → 0) hides that an operation can pass every latency test and still be expensive, or vice versa.
Not fixed by making each call faster. The lever is the number of sequential round trips on the critical path and whether they run in series or parallel — not the speed of any one call. Collapsing n calls into one (batch endpoints, eager loading), removing hops (caching), hiding them (prefetch), or parallelizing the unavoidable ones is the remedy; shaving microseconds off each of fifty serial calls is not. The N+1 query, deep synchronous fan-out, and a list view calling a detail endpoint per row are all the too-many-serial-hops shape.
Not disproven by a fast run on localhost. Loopback latency is near zero and light-load testing suppresses L, so the cost is invisible exactly where systems are designed and instrumented. A feature that is instant locally and seconds-slow in production is the signature, not a contradiction; a clean local run is silent about the round-trip term, not a clearance of it.

Scope of Application¶

The Fallacy of Zero Latency 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 (batch endpoints, eager loading, caching, prefetching, denormalization, data locality); its reach is within that domain (the transaction-cost, context-switching, and chatty-cross-team-handoff analogues are co-instances of the parent — the latency prime plus the cost-of-composition shape under the idealized-substrate meta-fallacy — but have no RPC surface or round-trip time, so the "denormalize / prefetch" machinery does not survive extraction).

Object-relational mapping / persistence layer — the home case: lazy-loading issues a separate query per row (the N+1 pattern), local-feeling code with remote-feeling latency, answered by batch endpoints and eager loading.
Microservice fan-out and service mesh — a single user request synchronously chaining ten downstream calls, each adding its tail latency, answered by collapsing or parallelizing hops.
Client-API design — a list view calling a detail endpoint once per item, answered by batched or shaped retrieval that fetches many records in one round trip.
Multi-region and cross-datacenter deployment — the cross-continent hop (tens to a hundred-plus milliseconds) that is invisible at design time and dominant in production, answered by data locality and call-count reduction.

Clarity¶

Naming this fallacy makes a per-call cost visible that local-call abstractions are specifically built to hide. Transparent RPC, ORM lazy-loading, and other "make remote look local" conveniences succeed at exactly the wrong thing — they erase the local/remote distinction from the call site, so the round-trip term L silently drops out of the developer's mental cost model. The label restores it as a first-class variable and hands the engineer one diagnostic: how many network hops does a single user action trigger, and what is the latency budget for each? That question turns call granularity, batching, caching, and prefetching from emergent accidents into explicit design decisions, and it makes the signature pathologies — N+1 query patterns, deep synchronous microservice fan-out, a list view that calls a detail endpoint once per row — recognizable as one error rather than unrelated performance bugs.

The distinction it sharpens is between number of calls and cost of the operation, which the zero-latency assumption collapses by making L = 0 so that n calls look free. Holding L > 0 reframes a composed operation's cost as at least n·L, compounding directly under sequential fan-out and growing super-linearly once tail latency means the slowest of n calls sets the total. That reframing is what lets the practitioner see why the whole corrective toolkit converges on a single principle — minimize sequential round trips on the critical path, and parallelize the unavoidable ones — rather than treating batch endpoints, eager loading, denormalization, and data locality as a grab-bag of tricks. It also locates the trap in development practice: because the latency is invisible on localhost and under light-load testing, the fallacy forms at the one scale where it cannot be observed and dominates at the scale where it decides whether the page loads in milliseconds or seconds.

Manages Complexity¶

A composed distributed operation can be slow for reasons that present as unrelated bugs — an ORM lazy-loading a query per row, a user request fanning out across ten downstream services, a list view calling a detail endpoint fifty times, a cross-region hop no one budgeted for — and a performance engineer chasing them individually faces a scattered catalogue of pathologies, each surfacing only under production load and invisible on localhost. The fallacy compresses that catalogue to one term in a single cost function: per-call latency L, wrongly set to zero, so that an operation making n remote calls actually costs at least n·L — compounding directly under sequential fan-out and growing super-linearly once tail latency lets the slowest of n calls set the total. With the cost model carrying L > 0, the disparate bugs collapse to one recognizable shape (too many sequential round trips on the critical path), and the whole corrective toolkit — batch endpoints, eager loading, caching, prefetching, denormalization, data locality — stops being a grab-bag and resolves into one principle: minimize sequential round trips, parallelize the unavoidable ones. The analyst no longer estimates each feature's latency from scratch but reads it off two numbers, the round-trip count on the critical path and the per-hop latency, turning "why is this slow and which trick fixes it?" into a low-dimensional budgeting question answerable at design time.

Abstract Reasoning¶

Carrying L > 0 in the cost function converts vague performance worry into a small set of quantitative inferences about composed operations.

Diagnostic (read round-trip count behind slowness). When a user-facing operation is slow in production but fast on localhost, the fallacy supplies the cause to look for: the omitted latency term, not local computation. Reason from the symptom to a count — estimate n, the number of sequential remote calls on the critical path, and multiply by per-hop L; if n·L approaches the observed wall-clock cost, the bottleneck is round trips, not CPU. The localhost-versus-production gap is itself diagnostic, because L is near zero on loopback and tens to hundreds of milliseconds across racks, datacenters, and continents — so a feature that is instant locally and seconds-slow remotely is almost certainly issuing many serial hops. The signature patterns — an ORM lazy-loading one query per row (N+1), a request fanning out through ten downstream services in series, a list view calling a detail endpoint once per item — are all read as the same shape: too many sequential round trips, not unrelated bugs.

Interventionist (cut or parallelize round trips). The lever is the round-trip count on the critical path and whether those trips run in series or parallel. Every corrective is a prediction about moving one of those quantities: a batch endpoint or eager loading collapses n calls into one (predicted effect: cost falls from n·L toward a single L); caching removes remote calls for slowly-changing data (predicted effect: those hops drop out of the budget entirely); prefetching pipelines a round trip behind computation (predicted effect: its latency is hidden rather than added); denormalization reduces how many calls are needed to assemble a response; data locality shrinks L itself by reducing physical distance. Where round trips are irreducible, issuing them in parallel rather than in series changes the cost from the sum of latencies toward the maximum of them — and the fallacy predicts the catch: under tail latency the slowest of n parallel calls sets the total, so the payoff of parallelizing is bounded by the tail, not the mean. The unifying intervention is therefore: minimize sequential round trips on the critical path, and parallelize the unavoidable ones.

Boundary-drawing (when zero latency is a safe approximation). The same cost model marks where the fallacy does not bite. If an operation makes few remote calls, or runs entirely against local memory, or its hops are off the user-visible critical path (background, asynchronous, amortized), then n·L is negligible and the transparent local-feeling abstraction is harmless — chasing batching and prefetching there is wasted effort. The boundary is the product n·L relative to the latency budget of the user action: small n, small L, or off-path calls keep the snapshot of "remote ≈ local" valid; large n on the critical path with non-trivial L is where it must be budgeted. Crucially, a clean localhost or light-load test does not certify the safe side, because that is exactly the regime where L is suppressed and the term is invisible.

Forward (budget at design time). Because the cost is n·L plus tail effects, the engineer can estimate an operation's production latency before it is built: count the round trips the proposed API granularity forces, multiply by realistic per-hop latency for the intended topology (same rack, cross-datacenter, cross-continent, mobile), and predict whether the page lands in milliseconds or seconds. That forward read turns API call-granularity — chatty versus batched, synchronous fan-out depth, where the data lives — into a design decision made against a number, rather than a performance surprise discovered under load.

Knowledge Transfer¶

Within distributed computing the fallacy transfers as mechanism, because every subfield that composes remote calls shares the same cost function n·L and the same corrective toolkit. From the persistence layer (ORM lazy-loading and the N+1 query pattern) to the service mesh (deep synchronous microservice fan-out) to client-API design (a list view calling a detail endpoint once per row) to multi-region deployment (the cross-continent hop no one budgeted), the diagnostic is identical — count the sequential round trips on the critical path, multiply by per-hop latency — and so is the remedy: collapse calls with batch endpoints or eager loading, drop hops with caching, hide them with prefetching, shrink them with denormalization or data locality, and parallelize what remains. The vocabulary (round-trip time, RPC, batch API, eager versus lazy) carries intact across these subfields; only the topology and the numbers change. The fallacy travels especially cleanly because it is one of a recognized family — the Fallacies of Distributed Computing (the Deutsch set) — and shares its skeleton with the sibling fallacies (infinite bandwidth, zero transport cost) that make the same move on a different idealized network property.

Beyond distributed computing the transfer is analogy, and the seam is the carrying machinery. The portable shape is general: the per-unit cost of an operation in a composed system is set to zero at design time and dominates in production once the operation count grows. That shape genuinely recurs — transaction costs in economics (each market interaction carries an overlooked friction), context-switching cost in cognition (each task hand-off is a hidden round trip), and the organizational case the seed names, where a workflow that fans a single request out across many cross-team hand-offs is "chatty" in exactly the structural sense. But these are the same shape, not the same mechanism: there is no network, no round-trip time, no RPC surface hiding a local/remote boundary, and the corrective vocabulary that gives the original its force (batch endpoints, eager loading, prefetch, data locality) does not apply — the organizational fix is to reduce hand-offs, not to "denormalize." Invoking "the zero-latency fallacy" off-substrate renames the components (network hop → market transaction or team hand-off, L → friction or coordination cost) and borrows the cost-compounding shape while dropping the networking machinery. The honest report is that the substrate-neutral content here is already carried by the latency prime (the irreducible-delay concept) plus the general cost-of-composition shape — and this entry is precisely the design fallacy that the prime acquires inside networked computing, which is why it is a domain-specific abstraction rather than the prime itself (see Structural Core vs. Domain Accent). Where the cross-domain lesson is actually needed, it is the prime and the general composition argument that should travel, not this fallacy as named.

Examples¶

Canonical¶

The N+1 query is the textbook instance. Rendering a page of 50 blog posts with each author's name, an ORM with lazy loading issues 1 query for the list of posts and then 1 additional query per post to fetch that post's author — 1 + 50 = 51 round trips. On localhost, where a query round-trips in roughly 0.1 ms, the whole operation costs about 5 ms and is invisible. Move the database one hop across a datacenter (L ≈ 1 ms) and the cost is 51 ms; move it cross-region (L ≈ 50 ms) and it is 51 × 50 ≈ 2,550 ms — a 2.5-second page. Switching to eager loading collapses the per-row fetches into a single WHERE author_id IN (...) query, so n falls from 51 to 2 and the cross-region cost drops from ~2,550 ms to ~100 ms.

Mapped back: Rendering the list is the composed operation; the per-query round trip is the irreducible per-hop latency L; ORM lazy loading is the distinction-hiding API that sets up the L=0 cost function. The clean 5 ms localhost run is the development-environment mask, the 51·L blow-up is the n·L compounding, and eager loading is the minimize-round-trips corrective cutting n from 51 to 2.

Applied / In Practice¶

Large-scale web services expose the same fallacy under parallel fan-out, where the tail rather than the mean dominates. Jeffrey Dean and Luiz Barroso documented this in "The Tail at Scale" (Communications of the ACM, 2013): if a user request fans out to 100 leaf services and each independently has just a 1% chance of taking longer than one second, then the probability that at least one is slow — and thus the whole request is slow — is 1 − (0.99)^100 ≈ 0.63. Sixty-three percent of requests breach the one-second mark even though any single service almost never does. Google-scale search and similar fan-out architectures budget explicitly against this, using techniques like hedged and tied requests to cut the tail rather than assuming each remote leaf returns as if local.

Mapped back: The fanned-out user request is the composed operation; each leaf's round trip carries the irreducible per-hop latency. Assuming each leaf returns as fast as a local call is the L=0 cost function; the 63% figure is the n·L compounding in its tail-latency form, where the slowest of n calls sets the total. Hedged requests are the minimize-round-trips corrective applied to the unavoidable, parallelized hops.

Structural Tensions¶

T1: Abstraction convenience versus cost visibility (the hiding API is both the win and the trap). Transparent RPC, ORM lazy-loading, and other make-remote-look-local conveniences are genuine productivity gains — they let an engineer compose distributed calls with local-code ergonomics, without threading network detail through every call site. That erasure of the local/remote boundary is exactly what drops the round-trip term L out of the developer's mental cost model, so the same feature that raises development velocity manufactures the fallacy. There is no version of the abstraction that hides the distinction for coding but reveals it for costing — the convenience and the blindness are one mechanism. Removing the abstraction restores visibility but forfeits the ergonomics; keeping it demands a separate discipline (explicit round-trip budgeting) to compensate for the very cost it was designed to conceal. Diagnostic: Does the call-site code make the local/remote boundary — and its L — visible where latency is budgeted, or is the abstraction hiding the hop at exactly the point the cost should be counted?

T2: Series versus parallel (parallelizing trades the sum for a tail that grows with fan-out). Where round trips are irreducible, issuing them in parallel moves the cost from the sum of latencies toward the maximum — a large win on the mean. But the fallacy carries its own catch: under tail latency the slowest of n parallel calls sets the total, and the probability that at least one of n legs is slow rises with n (the 63%-of-requests-breach result at 100 leaves). So parallelizing cures the sequential-compounding problem while exposing the operation to tail amplification that worsens with the very fan-out width parallelism encourages. The trade-off is that reducing mean latency by widening parallel fan-out raises tail latency, and past a point the tail, not the sum, is the binding cost. Diagnostic: Is the operation bound by the sum of serial hops (parallelize) or by the tail of a wide parallel fan-out (cut the fan-out or hedge the tail)?

T3: Cutting round trips versus spending other budgets (the cure shifts the cost, it does not delete it). Every corrective for n·L moves cost onto a different term. Batch endpoints and eager loading collapse call count but can over-fetch, inflating payload and the sibling transport-cost term c. Denormalization cuts the calls needed to assemble a response but duplicates data and buys a consistency burden. Caching removes hops for slowly-changing data but purchases staleness and invalidation complexity. Data locality shrinks L but constrains deployment and can concentrate load. The tension is that "minimize sequential round trips" is not free optimization — it is a reallocation from the latency budget to the bandwidth, consistency, or coupling budgets, and a design that passes every latency test may now fail on one of those. Diagnostic: When a round trip is cut, which budget absorbed the cost — payload, staleness, duplication, or coupling — and is that budget the one under less pressure?

T4: Design-time visibility versus production-time dominance (the mask cuts both ways). The fallacy forms at the one scale where it cannot be observed — localhost and light-load testing suppress L to near zero — and dominates at the scale that decides whether a page loads in milliseconds or seconds. This is not just a warning; it is a standing trade-off in how systems are developed. The fast, cheap, low-latency development environment that makes iteration pleasant is systematically blind to the cost term, so realistic latency and comfortable local development pull against each other: certifying the safe side requires deliberately reintroducing the latency the local environment removed (fault injection, realistic topology in staging), at the price of the ergonomics that made local testing attractive. A clean local run is silent about L, never a clearance of it. Diagnostic: Has the round-trip term been measured under production-realistic latency and topology, or is the confidence resting on a localhost run that structurally cannot see it?

T5: Budgeting the term versus over-engineering off the critical path (the n·L boundary). The cost model marks where the fallacy does not bite: few calls, small L, or hops that are asynchronous, background, or off the user-visible critical path make n·L negligible, and there the local-feeling abstraction is harmless. Chasing batch endpoints, prefetching, and denormalization in that regime spends real complexity — cache invalidation, over-fetch, duplicated data — to buy nothing. But the boundary is treacherous because the clean local test cannot certify the safe side, so an engineer is caught between premature optimization of harmless off-path calls and a latent blowup on the critical path that testing hid. The tension is that the same toolkit is essential on one side of n·L and pure over-engineering on the other, and the environment where the decision is made obscures which side you are on. Diagnostic: Is the operation's n·L on the user-visible critical path large enough to matter, or is the corrective being applied to calls whose latency is amortized, async, or off-path?

T6: Autonomy versus reduction (a distributed-systems fallacy or the latency prime acquiring a home domain). The Fallacy of Zero Latency is a genuine, named member of the Deutsch Fallacies of Distributed Computing, with its own computing-native cargo — the RPC surface that hides the local/remote boundary, the N+1 pattern, the batch/eager/prefetch/denormalize toolkit — and within distributed computing it transfers as literal mechanism because every subfield shares the n·L cost function. But its portable content is not proprietary: strip the networking and the shape is the general cost-of-composition argument (a per-unit cost set to zero at design time dominating in production as the operation count grows) riding on the latency prime (irreducible delay). That shape recurs as analogy in transaction costs, cognitive context-switching, and chatty cross-team hand-offs — but there is no round-trip time or RPC surface there, and "denormalize/prefetch" does not apply. This entry is precisely what the latency prime becomes inside networked computing. Diagnostic: Resolve toward the latency prime plus the cost-of-composition shape when carrying the lesson to economics, cognition, or org design; toward the named fallacy when budgeting round trips in an actual distributed API in situ.

Structural–Framed Character¶

The fallacy of zero latency sits at the framed-leaning position on the structural–framed spectrum, on the same footing as its Deutsch catalogue-mates. Despite "fallacy," it is an engineering design-defect diagnostic — a named false assumption relative to a real technical substrate whose round-trip time is genuinely irreducible (L > 0 is a physical fact of networks) — not a reasoning verdict, so it is anchored to something the world does even as its distinctive apparatus is all distributed-computing practice. Four criteria point framed; the substrate-anchoring keeps it off the framed pole.

On evaluative weight it is a diagnostic-normative charge: to name a design "the fallacy of zero latency" is to convict its cost function of dropping the L term, a real "budgeted wrong" verdict — but a design finding, not a moral conviction. On human-practice-bound it is high: the concept presupposes remote calls, APIs, RPC surfaces, and critical-path budgeting — remove the practice of building distributed software and there is no L=0 cost function, no N+1 pattern, nothing to compound. On institutional_origin it is strongly framed: the entry is explicitly a member of the canonical Deutsch "Fallacies of Distributed Computing", discipline design lore, and its corrective toolkit (batch endpoints, eager loading, prefetch, denormalization, data locality) is an artifact of that engineering tradition. On vocab_travels it scores low: round-trip time, RPC, N+1 queries, eager-versus-lazy loading, and hedged requests are distributed-computing terms with no counterpart in economics or org design. On import_vs_recognize the transfer is bimodal — within distributed computing the mechanism is recognized across the persistence layer, service mesh, client APIs, and multi-region deployment, but calling cognitive context-switching or a chatty cross-team handoff "the fallacy of zero latency" is import-by-analogy that drops the corrective bite, though the underlying cost-of-composition pattern genuinely recurs there as a co-instance.

The genuinely portable structural skeleton is the cost-of-composition argument on the latency prime: a per-unit cost (here the irreducible round-trip delay L) is set to zero at design time and dominates in production once the operation count n grows, so composed cost is at least n·L — the latency prime (irreducible delay) plus the general cost-of-composition shape, under the idealized-substrate meta-pattern. That skeleton is substrate-neutral and recurs as co-instances in transaction-cost friction, cognitive context-switching, and chatty inter-team handoffs. But it does not pull the fallacy off the framed-leaning region, because that skeleton is exactly what the entry instantiates from its parent — it is "what the latency prime becomes inside networked computing" — not what makes "fallacy of zero latency" itself travel: the cross-substrate lesson belongs to the latency prime and the composition argument, while the n·L cost model, the N+1/fan-out pathologies, and the batch/eager/prefetch toolkit — the distributed-computing accent — stay home. Its character: a substrate-anchored but engineering-practice-constituted, closed-catalogue design-defect label, structural only in the cost-of-composition / latency skeleton it instantiates from its parent.

Structural Core vs. Domain Accent¶

This section decides why the fallacy of zero latency is a domain-specific abstraction and not a prime, and it carries the case for its domain-specificity in the same breath — a case doubled here, since the entry is also a member of the closed Deutsch catalogue.

What is skeletal (could lift toward a cross-domain prime). Strip the network substrate and a thin relational structure survives: a per-unit cost of composition is set to zero at design time and dominates in production once the operation count grows, so a composed operation making n steps actually costs at least n·L, compounding directly in series and super-linearly once the tail sets the total. The portable pieces are abstract — an irreducible per-step delay, a composition that multiplies it, and the discipline of minimizing sequential steps and parallelizing the unavoidable ones. That skeleton is genuinely substrate-portable: it is the latency prime (irreducible delay) plus the general cost-of-composition shape, under the idealized-substrate meta-pattern. It recurs as real co-instances in domains with no packets — transaction-cost friction in economics, cognitive context-switching (each task hand-off a hidden round trip), and chatty cross-team hand-offs (a request fanned out across many crossings). But it is the core the fallacy shares with those co-instances, not what makes it the specific engineering defect it is.

What is domain-bound. Almost all the distinctive content is distributed-computing furniture that does not survive extraction. The per-hop delay is a network round-trip time L > 0 (microseconds same-rack, tens of ms cross-datacenter, 100ms+ cross-continent); the distinction-hiding culprits are transparent RPC and ORM lazy-loading; the signature pathologies are the N+1 query pattern, deep synchronous microservice fan-out, and a list view calling a detail endpoint per row; and the corrective toolkit is native — batch endpoints, eager loading, caching, prefetching, denormalization, data locality, and hedged/tied requests. Its identity is a Deutsch-catalogue fallacy. The worked cases — the 51-query N+1 blog page, Dean and Barroso's "The Tail at Scale" — are networked-software material. The decisive test: strip the infrastructure and the corrective vocabulary loses its referent — a cognitive or organizational "round trip" has no RPC surface hiding a local/remote boundary, no L to measure in milliseconds, and "denormalize/prefetch" does not apply; the organizational fix is to reduce hand-offs, not to shape a query.

Why this does not clear the prime bar. A prime is a relational structure whose vocabulary travels and whose cross-domain transfer is recognition of the same mechanism, not analogy — and it should be a free-standing structural unit. The fallacy of zero latency fails on both counts. Within distributed computing it transfers as literal mechanism — the n·L cost function, the round-trip-count diagnostic, and the minimize-and-parallelize corrective carry across the persistence layer, service mesh, client APIs, and multi-region deployment, because every subfield composes remote calls over the same cost function. Beyond computing, the machinery has no referent — the bare cost-of-composition shape survives, but the batch/eager/prefetch toolkit does not — so calling cognitive context-switching or a chatty cross-team handoff "the fallacy of zero latency" is import-by-analogy. And it is doubly disqualified: it is one member of the closed Deutsch catalogue, and its substrate-neutral content is precisely "what the latency prime becomes inside networked computing" — a specialization, not a free-standing prime. So when the bare structural lesson — a per-unit composition cost set to zero dominates as the count grows — is needed cross-domain, it is already carried, in more general form, by the latency prime plus the general cost-of-composition argument. The cross-domain reach belongs to those parents; "fallacy of zero latency," as named, is their distributed-computing instance, and its n·L cost model, N+1/fan-out pathologies, and batch/prefetch toolkit are domain baggage that should stay home.

Relationships to Other Abstractions¶

Current abstraction Fallacy of Zero Latency Domain-specific

Parents (1) — more general patterns this builds on

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 → Idealized-Substrate Fallacy → Abstraction

Not to Be Confused With¶

Fallacy of zero transport cost. The closest sibling and the one most easily merged with this. Latency is response time per round trip (L); transport cost is the per-byte resource charge (c) — serialization CPU, bandwidth, egress, battery. A design can move tiny payloads (cheap c) yet be latency-bound by many serial hops (n·L), or move huge payloads that pass every latency test while running up an egress bill. Tell: is the binding cost how long the round trips take (this entry) or how many bytes they move and what that charges (zero transport cost)?
Fallacy of infinite bandwidth. The sibling assuming throughput is unlimited (bytes per unit time the path carries). Latency is delay per round trip. A fat pipe can still be slow (high latency, high bandwidth), and a low-latency link can still be narrow. Tell: is the problem that each round trip is slow / there are too many of them (this entry) or that the path can't carry enough bytes per second (infinite bandwidth)?
The other Deutsch siblings (reliable network, secure network, stable topology, homogeneous networks, one administrator). Members of the same closed catalogue of eight, each a different substrate idealization. Zero latency is specifically the dropped per-hop round-trip term L. Tell: is the assumption that a remote call is as fast as a local one (this entry), or one of the delivery/trust/topology/uniformity/control idealizations (the siblings)?
N+1 query / chatty API (the signature pathology). These name a specific manifestation — an ORM issuing one query per row, a list view calling a detail endpoint per item — not the fallacy itself. They are instances of the too-many-serial-hops shape the zero-latency assumption produces; the fallacy is the underlying L=0 cost function that makes them look free. Tell: are you naming a particular chatty access pattern (a symptom/instance), or the design-time assumption that generates the whole family (this entry)?
The latency prime + cost-of-composition (parent). The substrate-neutral parent — an irreducible per-step delay that a composition multiplies (n·L), which recurs in transaction-cost friction, cognitive context-switching, and chatty cross-team handoffs. The fallacy of zero latency is what the latency prime becomes inside networked computing, adding the RPC surface and batch/prefetch toolkit the bare prime lacks. Tell: are you carrying the "a per-step delay dominates as the count grows" lesson to economics, cognition, or org design (the parent, treated more fully elsewhere), or budgeting round trips in a distributed API (this entry)?
The idealized-substrate meta-fallacy / assumption-audit (parent). The umbrella across all eight Deutsch fallacies — code silently assumes a frictionless idealization of its substrate. Zero latency is one child (the instant-delivery idealization). Tell: are you naming the general discipline of auditing an implicit substrate idealization (the meta-pattern), or specifically the dropped round-trip-time term (this entry)?

Neighborhood in Abstraction Space¶

Fallacy of Zero Latency sits in a moderately populated region (50^th percentile for distinctiveness): it has near-neighbors but no dense thicket of look-alikes.

Family — Unclustered & Miscellaneous (309 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-07-12