Skip to content

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.

Core Idea

The Fallacy of Zero Transport Cost is the design-time assumption that moving data between nodes in a distributed system is free — that the act of transmitting bytes over a network consumes no meaningful resources on the sending side, on the receiving side, or in the network infrastructure between them, and that the volume of data moved is therefore an unconstrained design variable. In reality every byte transported carries multiple real costs: serialization and deserialization CPU time on both endpoints; network bandwidth, which is a shared and finite resource; monetary egress fees in cloud environments, which can be substantial and are billed per gigabyte transferred across availability zones or out of the cloud provider's network; battery and cellular-data consumption on mobile and edge devices; and contention for shared queues and buffers that raises latency for all co-resident traffic. Designs authored in office broadband environments and tested on localhost treat these costs as zero because they are invisible at development scale; they discover them in production, at mobile-device traffic volumes, or on the cloud billing statement.

The structural error sits in the cost function that governs payload and API design choices. When the per-byte transport cost c is assumed to be zero, the cost of moving b bytes is b·c = 0, and payload size is a free variable. An API that returns the full user record when only the display name is needed, a backend that ships nested objects with fields no client will ever read, a microservice that polls for state by downloading the entire state document on each check — all of these are rational under a zero-transport-cost assumption and irrational once c > 0 is acknowledged. Unlike the latency fallacy, which shows up as increased response time, the transport-cost fallacy often manifests as a monetary or resource charge that appears only in production billing and is disconnected in time and space from the code that generated it, making causal attribution difficult and discouraging early correction.

The corrective is to make payload volume an explicit design variable alongside latency, correctness, and security. The toolkit is unified by the principle of moving only what the consumer will use: field projection (returning only requested fields rather than full objects, as GraphQL field selection formalizes), pagination (breaking large result sets into smaller transfers rather than shipping everything), compression (reducing bytes-on-wire at the cost of CPU, which is often a good trade), edge computation (moving transformation logic closer to the data rather than moving the data to the transformation), and caching (serving repeated reads from local state rather than re-transporting the same data). In ML data pipelines the same principle appears as the decision of whether to move raw data to a training cluster or to move the compute job to where the data already lives — a transport-cost calculation that can determine whether a workload is economically viable at all.

Structural Signature

Sig role-phrases:

  • the data-moving operation — a composed operation that transmits b bytes between nodes to do its work
  • the per-byte transport cost — the real c > 0 each byte carries: serialization CPU on both ends, finite shared bandwidth, metered egress, battery/cellular, buffer contention
  • the unconstrained-payload assumption — the design-time treatment of c as zero, so payload size b drops out as a free variable
  • the development-environment mask — office broadband and localhost make transport feel free, so the cost is invisible where designs are authored
  • the b·c charge — the cost of moving b bytes is at least b·c, growing with payload volume
  • the dislocated-charge signature — unlike latency, the cost surfaces as a resource charge (a billing line, a drained data plan) detached in time and space from the code that caused it
  • the path-dependence — the same payload is free within a zone yet expensive across a billed AZ, region, cloud egress, or cellular link
  • the move-only-what-is-used corrective — field projection, pagination, compression, edge computation, caching, all reducing b (or c by crossing fewer boundaries)
  • the move-data-or-move-compute calculation — comparing the b·c of shipping data to the compute against shipping the compute to the data, sometimes deciding viability outright
  • the substrate-bound limitation — serialization formats, GraphQL projection, egress pricing are computing-native; the transaction_costs prime is the parent of which this is the per-byte specialization

What It Is Not

  • Not a claim that bandwidth is always scarce. The fallacy is not that transport is expensive everywhere, but that the per-byte cost c is set to zero in design reasoning, so payload size drops out as a free variable. The cost is sharply path-dependent: the same payload is effectively free within a single host or an unbilled zone and expensive the moment it crosses a metered AZ, region, cloud-egress, or cellular boundary. The error is the omitted per-byte term on the paths where it is large, not transport cost in general.
  • Not the same as latency. Transport cost is a resource charge — serialization CPU on both endpoints, finite shared bandwidth, per-gigabyte egress, battery and cellular data, buffer contention — not response time. Its signature is exactly what distinguishes it from its latency sibling: the cost surfaces on a billing statement or a drained data plan, dislocated in time and space from the code that caused it, which is why it evades the call-site reasoning latency invites. Holding c → 0 apart from L → 0 is what reveals a design can pass every latency test and still be unviable.
  • Not a performance problem. The fallacy often manifests as money or energy, not slowness: a design can be perfectly fast and still run up cloud egress or exhaust a mobile data plan. Treating it as a latency or throughput issue misses that the binding constraint may be the bill, and that causal attribution is delayed precisely because the charge is detached from the request that generated it.
  • Not disproven by a clean office-broadband run. A design authored and tested on localhost and office Wi-Fi sits on the free side of the cost boundary by construction — no egress meter, no cellular allowance, no contention at that scale — so transport feels free exactly where it is built. That invisibility is not evidence of efficiency; the cost must be re-evaluated for the real deployment envelope (cross-region, out-of-cloud, cellular, at volume), where b·c becomes the dominant charge.

Scope of Application

The Fallacy of Zero Transport Cost lives within distributed computing — the subfields where a data-moving operation's cost function drops the per-byte term c, and the corrective toolkit is native (field projection, pagination, compression, edge computation, caching); its reach is within that domain (the logistics, manufacturing, and inter-team-coordination analogues are co-instances of the parent — the transaction_costs prime under the idealized-substrate meta-fallacy, of which this is the per-byte specialization — but have no projection query to return a subset, so the egress-and-projection machinery does not survive extraction).

  • API and payload design — the home: full-record responses for one field and chatty schemas shipping redundant nested objects, answered by field projection and pagination that move only the consumed subset.
  • Cloud economics — cross-region and cross-cloud egress fees, billed per gigabyte across AZ/region/provider boundaries, that dominate the bill when transport is treated as free at design time.
  • Mobile and edge — battery and cellular-data costs of needlessly large payloads, answered by smaller payloads and compression.
  • ML data pipelines — the move-the-data-to-compute versus move-the-compute-to-data decision, a b·c calculation that can determine whether a workload is economically viable at all.

Clarity

Naming this fallacy makes payload volume a first-class design variable instead of an unconstrained one. When transport is assumed free, the cost of moving b bytes is b·c = 0, so payload size simply drops out of the design conversation — and patterns that are rational under that assumption (return the whole user record for one field, ship nested objects no client reads, poll state by re-downloading the entire document) look fine until production. The label gives the engineer a sharp diagnostic: what does it cost per byte to move this data, and how many bytes does this design move? That forces transport into the same budget as latency, correctness, and security, and it unifies an otherwise scattered toolkit — field projection, pagination, compression, edge computation, caching — under one recognizable principle: move only what the consumer will actually use.

The distinction it sharpens hardest is against its sibling, the zero-latency fallacy, and the difference is what makes this one uniquely hard to catch. Latency manifests as response time at the call site, temporally adjacent to the offending code; transport cost manifests as a resource charge — serialization CPU on both endpoints, finite shared bandwidth, per-gigabyte cloud egress, battery and cellular data, contention in shared buffers — that surfaces on a billing statement or a mobile data plan, disconnected in time and space from the code that generated it. Holding the two cost terms apart (L → 0 versus c → 0) is what lets a practitioner see why a design can pass every latency test and still be economically unviable, and why causal attribution is so often delayed until the bill arrives. In data-intensive settings the same distinction reframes a basic architectural choice — move the data to the compute, or move the compute to the data — as a transport-cost calculation that can decide whether a workload runs at all.

Manages Complexity

The costs of moving data appear in forms that share no obvious surface — serialization CPU on both endpoints, a finite shared-bandwidth ceiling, a per-gigabyte cloud egress line on the bill, a drained mobile battery and spent cellular allowance, queue contention that slows co-resident traffic — and an engineer meeting them separately confronts a scatter of unrelated-seeming charges, most surfacing far from the code that caused them and only at production scale. The fallacy compresses that scatter to one term in a cost function: per-byte transport cost c, wrongly set to zero, so that moving b bytes costs b·c and payload size silently leaves the design conversation. Restoring c > 0 collapses the heterogeneous charges into a single budgeted quantity (bytes-on-wire times unit cost) and unifies an otherwise miscellaneous toolkit — field projection, pagination, compression, edge computation, caching — under one principle: move only what the consumer will use. It also keeps this term cleanly separated from its sibling L, which is what lets the analyst reason about why a design can pass every latency test yet remain economically unviable, and recast a basic architecture choice — move the data to the compute or the compute to the data — as one transport-cost comparison. The high-dimensional question "which of many incommensurable resource charges will this design incur, and where?" reduces to the low-dimensional one of estimating bytes moved against per-byte cost.

Abstract Reasoning

Carrying c > 0 in the cost function gives the engineer inferences about resource charges that, unlike latency, do not announce themselves at the call site.

Diagnostic (trace a resource charge back to bytes moved). When a cloud bill shows a large egress line, a mobile user reports drained battery or a spent data plan, or co-resident traffic slows under buffer contention, the fallacy supplies the move the symptom resists: attribute the charge to payload volume, even though the charge surfaces far in time and space from the code that produced it. Reason from the charge to an estimate of b·c — multiply the bytes a design moves by the per-byte cost on that path (cross-AZ, cross-region, out-of-cloud, cellular) — and identify the offending pattern: an API returning the full record for one field, nested objects with fields no client reads, a poller re-downloading an entire state document each cycle. The tell that distinguishes this from its latency sibling is where the cost shows up: not as response time adjacent to the call, but as a serialization-CPU spike, a bandwidth saturation, or a billing-statement entry detached from the request that caused it — which is exactly why causal attribution is delayed and the fix discouraged.

Interventionist (move only what the consumer uses). The lever is bytes-on-wire, and every corrective is a prediction about reducing the b in b·c: field projection returns only requested fields (predicted effect: payload shrinks to the consumed subset, egress and serialization fall proportionally); pagination breaks a large result set into smaller transfers (predicted effect: bytes moved track what is actually read rather than the whole set); compression trades CPU for fewer bytes-on-wire (predicted effect: lower transport charge at a usually-favorable CPU cost); caching serves repeated reads locally (predicted effect: redundant re-transports drop out entirely); edge computation moves transformation to the data instead of moving the data to the transformation (predicted effect: only the small result crosses the expensive boundary). The unifying intervention is to move only what the consumer will use, and the per-byte framing tells you which lever pays most — on a metered or long-haul path even a modest byte reduction has outsized effect because c there is large.

Boundary-drawing (when transport is effectively free). The same parameter marks where the fallacy does not bite: inside a single host, within a zone where egress is unbilled, on broadband where the data plan is irrelevant, or for payloads small enough that b·c is negligible against the resources in play, transport can be treated as free and the projection/pagination/compression toolkit is needless complexity. The boundary is the product b·c relative to the budget that matters on the deployment path — and crucially it is path-dependent, because the same payload that is free within a zone becomes expensive the moment it crosses a billed AZ, region, cloud egress, or cellular link. A design validated in an office-broadband, localhost setting sits on the free side of that boundary by construction, which is why the cost is invisible there and must be re-evaluated for the real deployment envelope.

Architectural (move the data or move the compute). For data-intensive workloads the fallacy supports a decisive forward calculation: compare the cost of moving raw data to where the computation lives against the cost of moving the computation to where the data already is, each as a b·c term over the relevant boundary. The prediction is that when the dataset is large and the boundary is expensive, moving the compute to the data is cheaper — and the comparison can determine whether the workload is economically viable at all, not merely faster or slower. This recasts a basic placement decision as a transport-cost estimate made at design time rather than discovered on the bill.

Knowledge Transfer

Within distributed computing the fallacy transfers as mechanism, with its diagnostics and corrective toolkit intact. The c > 0 framing, the bytes-on-wire cost term b·c, the move-only-what-the-consumer-uses principle, and the path-dependence of the boundary carry across the subfields without translation: API and payload design (full-record responses, redundant nested objects — answered by field projection and pagination), cloud economics (cross-region and cross-cloud egress fees — answered by reducing bytes across billed boundaries), mobile and edge (battery and cellular-data costs — answered by smaller payloads and compression), and ML data pipelines (the move-the-data-to-compute versus move-the-compute-to-data decision). A performance or cost engineer reads the same tell (a charge that surfaces on the bill or the data plan, detached in time and space from the code that caused it — the feature that distinguishes this from its latency sibling) and reaches for the same lever (shrink b, or shrink c by crossing fewer billed boundaries) in each. These are co-instances of one transport-budgeting discipline, not analogies, because each literally moves bytes that consume serialization CPU, finite bandwidth, and metered egress, and the toolkit (projection, pagination, compression, edge computation, caching) means the same thing throughout.

Beyond computing the honest reading is case (B), and here the parent is unusually well-pinned: the broader prime transaction_costs — the friction attached to each unit of exchange in any composed system — already exists at the substrate-independent level, and this fallacy is precisely its networking specialization (the friction is per-byte transport). The general shape (a per-unit cost mis-modeled as zero in design reasoning, dominating once the volume grows) genuinely recurs as co-instances rather than resemblances: logistics and manufacturing (per-shipment or per-move friction ignored until volume scales), and cognitive/organizational "transmission" between team members (each hand-off carrying overlooked coordination cost). In each, the same abstract correctives apply — move only what is needed, batch or compress the transfers, relocate the work to reduce crossings — and the lesson should be carried by the transaction_costs parent (with network_flow_models the optimization relative that addresses routing the resulting load). That meta-pattern is also shared across the canonical Deutsch "Fallacies of Distributed Computing," whose common skeleton is an idealized, frictionless substrate assumed where the real one charges per unit moved (the proposed idealized-substrate fallacy meta-prime). What does not travel is the home-bound cargo: the corrective machinery is computing-native — serialization formats, GraphQL field selection, compression codecs trading CPU for bytes, cloud egress pricing across AZ/region/provider boundaries, edge computation — and the failure signatures (a 2 MB JSON blob per screen open, an egress line on the bill) presuppose that infrastructure. Strip it and the diagnostic loses its bite: a logistics network has the same per-unit-cost-as-zero mistake but no "projection query" to return a subset of a shipment. So invoking "the zero-transport-cost fallacy" for supply-chain friction borrows the cost-compounding shape while dropping the projection-and-egress machinery that gives the original its bite; that is analogy, and the cross-substrate lesson belongs to the transaction_costs prime and the idealized-substrate meta-pattern, of which this is the networking-specific manifestation, not to the fallacy as named (see Structural Core vs. Domain Accent).

Examples

Canonical

The fallacy is the eighth of the "Fallacies of Distributed Computing" (the original seven attributed to L. Peter Deutsch, with "transport cost is zero" added by James Gosling). The textbook instance is an over-fetching API. A mobile app's contacts screen needs only each contact's display name, but the endpoint returns each full user record — profile, preferences, nested address objects — say roughly 4 KB per record where the consumed field is about 40 bytes. For one screen listing 100 contacts that is ~400 KB moved to use ~4 KB. Across a million screen-opens a day the design ships on the order of 400 GB where ~4 GB would do, most of it serialized, transmitted over cellular links, and (if the API sits in another region) billed as per-gigabyte egress. On localhost none of this was visible.

Mapped back: The endpoint call is the data-moving operation shipping b bytes; treating payload size as free is the unconstrained-payload assumption (c set to zero). The ~100× gap between bytes moved and bytes used is the b·c charge made explicit. That it was invisible in development is the development-environment mask, and its later appearance as cellular-data and egress charges rather than slow responses is the dislocated-charge signature distinguishing it from latency.

Applied / In Practice

Hadoop's MapReduce was engineered around exactly this cost term through its data locality principle. Rather than pulling data blocks across the network to wherever compute is free, the job scheduler places each map task, where possible, on the very node (or rack) that already holds the input block on its local disk, so computation moves to the data instead of the data moving to the computation. The motivation is explicit in the design: network bandwidth in a large cluster is the scarce, shared resource, and moving terabytes of input to remote workers would saturate it. By shipping the small compiled task to the large data, only modest intermediate results cross the network — the move-the-compute-to-the-data resolution of the transport-cost calculation.

Mapped back: Reading an input block is the data-moving operation; cluster bandwidth as the finite shared resource is the per-byte transport cost c > 0. Scheduling tasks onto the nodes holding their data is the move-data-or-move-compute calculation resolved toward moving compute, because the dataset's b is huge and the network boundary expensive. Data locality is thus the move-only-what-is-used corrective at cluster scale — only small results, not raw inputs, cross the wire.

Structural Tensions

T1: Path-dependent cost versus universal correction (the same design is right on one path and over-engineered on another). The fallacy's own insight is that c is sharply path-dependent: a payload is effectively free within a host or an unbilled zone and expensive the moment it crosses a metered AZ, region, egress, or cellular boundary. This cuts both ways. It correctly explains why a localhost-validated design is unviable in production — but it equally means applying the projection/pagination/compression toolkit everywhere is needless complexity where b·c is negligible, a premature optimization that trades real developer time and code clarity for savings that do not exist on that path. Worse, a system spanning mixed paths (cheap intra-zone, expensive cross-region) has no single right payload. The parameter that catches the fallacy also condemns its own over-application. Diagnostic: On the specific deployment path this data crosses, is b·c large against the budget that binds — or is the transport-reduction machinery being added where transport is effectively free?

T2: Shrinking bytes-on-wire versus the costs the correctives themselves incur (the cure has its own bill). Every lever that reduces b (or c) pays in a different currency. Pagination shrinks per-transfer bytes but multiplies round-trips, feeding the latency fallacy it is supposedly separate from. Field projection and GraphQL selection add API surface and query complexity. Compression trades CPU for bytes — favorable often, but not on CPU-bound endpoints. Caching removes redundant re-transports but imports staleness and invalidation. Edge computation cuts bytes across the boundary but distributes logic and complicates deployment. So "move only what the consumer uses" does not eliminate cost; it converts transport cost into complexity, latency, CPU, or consistency cost. The tension is that the corrective is itself a trade, and a design can over-rotate on transport and lose more elsewhere than it saved on the wire. Diagnostic: Does the chosen corrective's added cost (round-trips, staleness, CPU, code complexity) come in under the transport cost it removes on this path — or is it just relocating the charge to a currency you are not counting?

T3: One unifying term b·c versus the incommensurable currencies it flattens (a scalar over dollars, joules, CPU, and contention). The model's compression collapses serialization CPU on both endpoints, finite shared bandwidth, per-gigabyte egress dollars, battery and cellular allowance, and buffer contention into a single per-byte cost c and one budgeted quantity b·c. That is exactly what makes the sprawl tractable — but these are genuinely different currencies that do not convert cleanly: optimizing for egress dollars need not help a drained battery, and buffer contention is a shared-resource externality that scales nonlinearly with co-resident traffic, not a clean per-byte charge on your own request. Treating c as one scalar can point the engineer at the wrong lever when the binding constraint is a currency the aggregate hides. The single term that unifies the toolkit also obscures which cost actually binds. Diagnostic: Is c here really one budget, or several (dollars, energy, CPU, contention) that diverge — and is the design optimizing the currency that is actually binding rather than the aggregate?

T4: A productive abstraction versus its leak (location transparency is valuable, and that is why the fallacy persists). Treating transport as free is not mere carelessness; it is the shadow side of a genuinely useful abstraction. Making a remote call look like a local one — location transparency, RPC-as-function-call, "the network is just another layer" — buys real developer productivity, portability, and simplicity, and distributed systems are tractable to build partly because designers do not price every byte. The zero-transport-cost fallacy is the leak in that abstraction, not the failure of a bad one: the same simplification that lets an engineer compose services without a transport budget is the one that hides b·c until the bill arrives. The tension is that fully pricing transport at design time erodes the very abstraction that makes the system buildable, while trusting the abstraction reintroduces the fallacy. Diagnostic: Is the transport-free abstraction here paying for itself in developer velocity and portability, or has its leak grown large enough (production egress, mobile data) that the payload must be priced explicitly despite the loss of transparency?

T5: Design-time budgeting versus production-only measurability (you must estimate the number you cannot yet see). The corrective is to make payload volume an explicit design-time variable — but the fallacy's defining signature is that the charge is dislocated in time and space, invisible in the office-broadband, localhost environment where designs are authored, and only revealed at production scale on a billing statement or a data plan. So the engineer is asked to budget b·c before either factor is truly knowable: c depends on a deployment topology that may not be fixed, and b depends on real usage patterns not yet observed. This risks error in both directions — under-budgeting a cost that only production reveals, or over-budgeting against a path that turns out cheap and paying for correctives that never earned back. The demand to price transport up front collides with the fact that its true price is a production discovery. Diagnostic: Is the design-time transport estimate grounded in the real deployment envelope and expected usage, or is it a guess that production will either vindicate or expose — and is the design instrumented to attribute the charge back to the code when it does surface?

T6: Autonomy versus reduction (a named distributed-computing fallacy or the networking instance of transaction costs). The Fallacy of Zero Transport Cost is a specific, canonically numbered member of the Fallacies of Distributed Computing with irreducibly computing-native cargo — serialization formats, GraphQL field selection, compression codecs, cloud egress pricing across AZ/region/provider boundaries, edge computation, the b·c cost term — and within distributed computing it transfers as literal mechanism across API design, cloud economics, mobile/edge, and ML pipelines. But beyond computing it does not travel as the named fallacy: it is precisely the networking specialization of the prime transaction_costs (per-unit exchange friction mis-modeled as zero), with network_flow_models as the routing relative, and it shares the idealized-substrate skeleton common to all the Fallacies. Logistics friction and inter-team coordination overhead are co-instances of that parent, but a supply chain has no projection query to return a subset of a shipment. The tension is between a fallacy that earns its own egress-and-projection machinery and the recognition that its cross-substrate lesson belongs to transaction_costs. Diagnostic: Resolve toward transaction_costs (and the idealized-substrate meta-pattern) when the point is per-unit friction mis-modeled as zero outside computing; toward the named fallacy when budgeting payload bytes against transport cost in a distributed system.

Structural–Framed Character

The fallacy of zero transport cost 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 per-byte transport genuinely costs (serialization CPU, finite bandwidth, metered egress are real charges) — 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 transport cost" is to convict its cost function of dropping the per-byte term c, a real "budgeted wrong / unviable" verdict — but a design finding, not a moral conviction. On human-practice-bound it is high: the concept presupposes APIs, payloads, serialization, cloud billing, and data pipelines — remove the practice of building distributed software and there is no c=0 assumption, no over-fetching endpoint, no egress line, nothing to charge. On institutional_origin it is strongly framed: the entry is explicitly the eighth of the canonical Deutsch "Fallacies of Distributed Computing" (Gosling's addition), discipline design lore, and its corrective toolkit (field projection, pagination, compression, edge computation, caching) is an artifact of that engineering tradition. On vocab_travels it scores low: serialization formats, GraphQL field selection, cloud egress pricing, and the b·c term are distributed-computing terms with no counterpart in logistics or org coordination. On import_vs_recognize the transfer is bimodal — within distributed computing the mechanism is recognized across API design, cloud economics, mobile/edge, and ML pipelines, but calling supply-chain friction "the zero-transport-cost fallacy" is import-by-analogy that drops the egress-and-projection machinery, though the underlying per-unit-friction pattern genuinely recurs there as a co-instance.

The genuinely portable structural skeleton is transaction costs — per-unit exchange friction mis-modeled as zero: a per-unit cost (here the per-byte transport cost c) is set to zero in design reasoning and dominates once the volume b grows, so composed cost is at least b·c — the transaction_costs prime of which this is precisely the networking specialization (with network_flow_models as the routing relative), under the idealized-substrate meta-pattern. That skeleton is substrate-neutral and recurs as co-instances in logistics and manufacturing per-move friction and inter-team coordination overhead. 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 the per-byte specialization of transaction_costs — not what makes "fallacy of zero transport cost" itself travel: the cross-substrate lesson (move only what is needed, batch or compress, relocate the work to reduce crossings) belongs to transaction_costs, while the b·c cost model, the dislocated-charge signature, and the projection/pagination/egress machinery — the distributed-computing accent — stay home. Its character: a substrate-anchored but engineering-practice-constituted, closed-catalogue design-defect label, structural only in the transaction-costs skeleton it instantiates from its parent as the per-byte specialization.

Structural Core vs. Domain Accent

This section decides why the fallacy of zero transport cost 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 (the entry is also a member of the closed Deutsch catalogue) and unusually clean, because its parent already exists at the substrate-independent level.

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 moving a thing is set to zero in design reasoning, so volume drops out as a free variable and the cost b·c dominates once the volume grows. The portable pieces are abstract — a per-unit exchange friction, a volume that multiplies it, and the discipline of moving only what the consumer will use (shrink the volume, or relocate work to cross fewer boundaries). That skeleton is genuinely substrate-portable, and here the parent is unusually well-pinned: this fallacy is precisely the networking specialization of the transaction_costs prime — the friction attached to each unit of exchange in any composed system — with network_flow_models as the routing relative, under the idealized-substrate meta-pattern. It recurs as real co-instances in domains with no bytes — logistics and manufacturing per-shipment friction ignored until volume scales, and inter-team "transmission" overhead where each hand-off carries coordination cost. 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-byte cost c bundles serialization CPU on both endpoints, finite shared bandwidth, metered cloud egress, battery/cellular, and buffer contention; the signature is the dislocated charge (a billing line or a drained data plan detached in time and space from the causing code); the cost is sharply path-dependent across AZ/region/cloud-egress/cellular boundaries; and the corrective toolkit is native — field projection (GraphQL selection), pagination, compression codecs, edge computation, caching, plus the move-data-or-move-compute placement calculation. Its identity is a Deutsch-catalogue fallacy. The worked cases — the over-fetching 4 KB-for-40-bytes contacts API, Hadoop MapReduce data locality — are networked-software material. The decisive test: strip the infrastructure and the diagnostic loses its bite — a logistics network has the identical per-unit-cost-as-zero mistake but no projection query to return a subset of a shipment, no egress meter, no serialization format.

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 transport cost fails on both counts, and unusually explicitly, because its parent transaction_costs already occupies the substrate-independent level this fallacy would otherwise claim. Within distributed computing it transfers as literal mechanism — the c > 0 framing, the b·c term, the move-only-what-is-used principle, and the path-dependent boundary carry across API/payload design, cloud economics, mobile/edge, and ML pipelines, because each literally moves bytes consuming serialization CPU, bandwidth, and egress. Beyond computing, the machinery has no referent — the bare per-unit-friction shape survives, but the projection-and-egress toolkit does not — so calling supply-chain friction "the zero-transport-cost fallacy" is import-by-analogy. And it is doubly disqualified: it is one member of the closed Deutsch catalogue, and it is expressly the per-byte specialization of transaction_costs, not a free-standing prime. So when the bare structural lesson — per-unit exchange friction mis-modeled as zero, dominating as volume grows — is needed cross-domain, it is already carried, in more general form, by the transaction_costs prime (with network_flow_models for routing the resulting load) under the idealized-substrate meta-pattern. The cross-domain reach belongs to that parent; "fallacy of zero transport cost," as named, is its networking instance, and its b·c cost model, dislocated-charge signature, and projection/pagination/egress machinery are domain baggage that should stay home.

Relationships to Other Abstractions

Local relationship map for Fallacy of Zero Transport CostParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Fallacy of ZeroTransport CostDOMAINPrime abstraction: Idealized-Substrate Fallacy — is a kind ofIdealized-Subst…PRIME

Current abstraction Fallacy of Zero Transport Cost Domain-specific

Parents (1) — more general patterns this builds on

  • 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

Not to Be Confused With

  • Fallacy of zero latency. The closest sibling and the one most easily merged with this. Transport cost is a per-byte resource charge (c) — serialization CPU, bandwidth, egress, battery — surfacing on a bill; latency is response time per round trip (L), surfacing at the call site. A design can be perfectly fast yet run up cloud egress, or cheap in bytes yet slow from many serial hops. Their signatures differ in where the cost shows up: adjacent to the code (latency) versus dislocated on the bill (this entry). Tell: is the binding cost how long it takes (zero latency) or how many bytes it moves and what that charges (this entry)?

  • Fallacy of infinite bandwidth. The very close sibling assuming throughput capacity is unlimited (bytes per unit time the path carries). Transport cost is the per-byte price of moving bytes — the two co-occur but are distinct: bandwidth is the finite pipe width, transport cost is the metered charge (egress $, CPU, battery) each byte incurs even when the pipe is wide. Tell: is the constraint that the path can't carry enough bytes per second (infinite bandwidth) or that each byte moved costs a resource/dollar (this entry)?

  • The other Deutsch siblings (zero latency aside — reliable network, secure network, stable topology, homogeneous networks, one administrator). Members of the same closed catalogue of eight, each a different substrate idealization. Zero transport cost is specifically the dropped per-byte cost term c. Tell: is the assumption that moving data is free (this entry), or one of the delay/delivery/trust/topology/control idealizations (the siblings)?

  • Over-fetching / chatty payloads (the signature pathology). These name a specific manifestation — returning a full record for one field, shipping nested objects no client reads — not the fallacy itself. They are instances of the move-more-than-needed shape the zero-cost assumption produces; the fallacy is the underlying c=0 cost function that makes big payloads look free. Tell: are you naming a particular over-fetching pattern (a symptom/instance), or the design-time assumption that generates the whole family (this entry)?

  • Transaction costs (parent). The substrate-neutral prime the fallacy is the per-byte specialization of — the friction attached to each unit of exchange in any composed system, mis-modeled as zero and dominating as volume grows. It already occupies the cross-domain level, recurring in logistics per-move friction and inter-team coordination overhead. The fallacy adds the egress/serialization/projection machinery transaction_costs lacks. Tell: are you carrying the "per-unit exchange friction mis-modeled as zero" lesson beyond computing (the parent, treated more fully elsewhere), or budgeting payload bytes against transport cost in a distributed system (this entry)?

  • The idealized-substrate meta-fallacy / network_flow_models (parents). The umbrella across all eight Deutsch fallacies (a frictionless substrate idealization), and the optimization relative that addresses routing the resulting load rather than sizing it. Zero transport cost is one child of the meta-pattern (the free-transfer idealization). Tell: are you naming the general substrate-idealization discipline or a flow-routing optimization (the parents), or specifically the dropped per-byte cost term (this entry)?

Neighborhood in Abstraction Space

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

Family — Unclustered & Miscellaneous (309 abstractions)

Nearest neighbors

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