Fallacy of Zero Transport Cost¶

Reject the design-time assumption that moving data between nodes is free by restoring the per-byte cost term to the cost function, so payload volume becomes an explicit design variable budgeted alongside latency.

Version: v4 · 2026-09-28 · History · 1 correction
Domain-specific #: 380
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 Transport Cost is the design-time assumption that moving data between nodes is free, so payload volume becomes an unconstrained design variable. In reality every byte carries real costs: serialization CPU on both endpoints, finite shared bandwidth, metered cloud egress, battery and cellular data, and buffer contention. With per-byte cost c set to zero, moving b bytes costs b·c = 0; restoring c > 0 makes payload size a first-class variable, corrected by moving only what the consumer uses.

How would you explain it like I'm…

Don't Mail the Toybox

Imagine your friend asks for one sticker, and you mail them your whole giant toy box. Mailing big boxes costs money and work, even if you don't see the bill right away. The Fallacy of Zero Transport Cost is building computer programs as if sending stuff between computers were free. The smart way is to send only what your friend actually needs.

Sending Data Isn't Free

Computers in a big system are always sending data to each other. The Fallacy of Zero Transport Cost is acting as if that sending is free. In fact it uses computer effort to pack and unpack data, takes up shared network space, drains phone batteries and data plans, and in the cloud companies pay per gigabyte moved. Programmers often don't notice because their test setup is fast and free, and then a big bill shows up later. The fix is simple to say: only send the data that will actually be used.

Every Byte Costs Something

The Fallacy of Zero Transport Cost assumes that moving data across a network uses no meaningful resources, so payload size doesn't matter. In fact every byte costs CPU time to serialize and deserialize, shared bandwidth, cloud fees for data leaving a zone or provider, mobile battery and data, and congestion that slows other traffic. Examples of the mistake include an API returning a whole user record when only a name is needed, or a service downloading an entire state document every time it checks for changes. Unlike slow response times, these costs often show up later on a bill, far from the code that caused them, so they're hard to trace. The fix is to move only what the consumer uses, through field selection, pagination, compression, caching, and computing closer to the data.

The Fallacy of Zero Transport Cost is the design assumption that transmitting data imposes no meaningful cost on sender, receiver, or network, which makes payload volume an unconstrained design variable. Real costs include serialization and deserialization CPU at both ends, finite shared bandwidth, per-gigabyte cloud egress fees across availability zones or out of the provider, battery and cellular data on mobile and edge devices, and queue and buffer contention that raises latency for co-resident traffic. If per-byte cost c is taken as zero, sending b bytes costs b·c = 0. That makes over-fetching full records, shipping unread nested fields, and polling by re-downloading whole state documents all look rational. Once c > 0, they don't. Unlike the latency fallacy, the damage often shows up as a billing or resource charge disconnected in time and place from the code that caused it, which makes attribution and early correction hard. The corrective principle is to move only what the consumer will use, through field projection (as in GraphQL field selection), pagination, compression, edge computation, and caching. In ML pipelines the same calculation decides whether to move raw data to compute or compute to data, and it can determine whether a workload is economically viable.

Scope of Application¶

The fallacy lives within distributed computing, the subfields where a data-moving operation's cost function drops the per-byte term and the corrective toolkit is native.

API and payload design — full-record responses and chatty schemas, answered by field projection and pagination.
Cloud economics — cross-region and cross-cloud egress fees billed per gigabyte.
Mobile and edge — battery and cellular-data costs of oversized payloads.
ML data pipelines — the move-the-data versus move-the-compute decision.

Clarity¶

Naming the fallacy makes payload volume a first-class design variable and unifies a scattered toolkit — projection, pagination, compression, edge computation, caching — under one principle: move only what the consumer uses. It sharpens the distinction against the zero-latency fallacy: transport cost surfaces as a resource charge on a bill, dislocated in time and space from the code that caused it.

Manages Complexity¶

Incommensurable charges — serialization CPU, bandwidth, egress, battery, contention — compress to one cost-function term, b·c. Restoring c > 0 collapses them into a single budgeted quantity, keeps it cleanly separated from latency L, and reduces "which charges will this incur, and where?" to estimating bytes moved against per-byte cost.

Abstract Reasoning¶

Carrying c > 0 licenses a diagnostic (trace a resource charge back to bytes moved), an interventionist move (shrink b via projection, pagination, compression, caching, edge), boundary-drawing on where transport is effectively free (path-dependent on b·c), and an architectural calculation (move the data or move the compute) that can decide viability.

Knowledge Transfer¶

Within distributed computing the fallacy transfers as mechanism across API design, cloud economics, mobile/edge, and ML pipelines, the b·c framing and toolkit carrying intact. Beyond computing the parent is the well-pinned Transaction Costs prime — per-unit friction mis-modeled as zero — of which this is the per-byte networking specialization (with Network Flow Models nearby and an idealized-substrate meta-fallacy shared across Deutsch's fallacies). The egress-and-projection machinery stays home.

Relationships to Other Abstractions¶

Current abstraction Fallacy of Zero Transport Cost Domain-specific

Parents (1) — outgoing typed relations

Fallacy of Zero Transport Cost is a kind of Idealized-Substrate Fallacy Prime

The fallacy of zero transport cost is the idealized-substrate fallacy specialized to data movement whose omitted friction is positive transfer cost.

Hierarchy path (1) — routes to 1 parentless root

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

Neighborhood in Abstraction Space¶

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

Family — Unclustered & Miscellaneous (2769 abstractions)

Nearest neighbors

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