Manu's Vault

Fallacy Transport Cost Is Zero

5 min readStatus:Seedling

Core Idea

“Transport cost is zero” is the seventh of the Fallacies of Distributed Computing—the false assumption that moving data across the network is free. In reality, network transport imposes both direct financial costs (bandwidth fees, infrastructure) and indirect costs (latency overhead, serialization/deserialization CPU cycles, increased operational complexity). Ignoring transport costs leads to architectures that make inefficient trade-offs between local computation and remote data access.

What Is the “Transport Cost Is Zero” Fallacy?

The False Assumption: The “transport cost is zero” fallacy is the assumption that network communication is a cost-free operation that can be used liberally without considering the economic and computational overhead it imposes.

The Reality: This assumption leads architects to design systems that freely call remote services, transfer data across network boundaries, or distribute computation without analyzing whether the transport cost justifies the architectural benefits. However, transport always costs something—whether measured in dollars, CPU cycles, latency, or energy consumption.

Direct Financial Costs: Transport costs are often overlooked:

  • Cloud providers charge for:
    • Data egress (data leaving their network)
    • Inter-region transfers
    • Cross-availability-zone traffic
  • AWS example pricing:
    • ~$0.09 per GB for data transfer out to the internet
    • $0.01-0.02 per GB for inter-region transfers
  • Real-world impact: A microservices system transferring 10 GB per day between regions accumulates $100-200 per month in pure bandwidth costs—before considering compute, storage, or other infrastructure costs
  • For high-throughput systems processing terabytes daily, transport costs can exceed compute costs

Indirect Computational Costs: Every network call requires:

  • Serializing data structures into transferable formats (JSON, Protocol Buffers, Avro)
  • Transmitting the serialized bytes
  • Deserializing them on the receiving end
  • Serialization/deserialization consumes CPU cycles proportional to data complexity and size
  • Impact: A microservice making hundreds of external calls per request may spend more CPU time on serialization than on business logic
  • This overhead doesn’t exist in monolithic architectures where in-process method calls pass object references directly without marshaling

When the Fallacy Becomes Problematic: Systems choose remote calls over local computation without cost analysis:

  • Example: Recommendation engine that could cache user preference data locally versus fetching it from a remote service on every request
    • Remote call pattern might seem simpler architecturally
    • But imposes: network latency, bandwidth consumption, serialization overhead, and potential availability dependencies
    • If preference data changes infrequently, caching with periodic refresh likely offers better cost-performance trade-offs than real-time remote fetching

Interaction with Bandwidth Fallacy: Transport costs interact with the bandwidth fallacy:

  • Not only does bandwidth have finite capacity, but using that capacity costs money
  • A chatty protocol that makes many small requests consumes bandwidth inefficiently
  • Each request includes protocol overhead (HTTP headers, TCP/IP framing, TLS handshake amortization)
  • Consolidating multiple small requests into fewer large requests reduces both bandwidth consumption and per-request overhead, lowering overall transport cost

Addressing the Fallacy - Cost-Aware Architectural Decisions:

  • Analyze whether distributing a service justifies transport costs
  • Use caching strategies to minimize repeated remote data fetches
  • Batch operations to amortize serialization and protocol overhead across multiple logical operations
  • Choose efficient serialization formats—binary protocols like Protocol Buffers or Avro reduce payload sizes compared to text-based JSON
  • Colocate services that communicate frequently to minimize inter-region or internet-bound traffic
  • Implement API gateways to aggregate multiple backend calls into single client-facing requests

Why This Matters

Direct Impact on Operational Costs and Performance:

  • Organizations often discover transport costs late, after deploying distributed architectures that generate unexpected cloud bills
  • Example: A microservices architecture might deliver excellent scalability and deployment independence, but if it incurs $10,000 per month in cross-region bandwidth charges, that cost must be weighed against architectural benefits
  • Cost analysis should inform architecture style selection, not be discovered post-deployment

Forces Trade-offs in Architecture Decisions: Understanding transport costs forces deliberate trade-offs in monolithic versus distributed decisions:

  • Monolithic architectures: Eliminate transport costs by keeping communication in-process, but sacrifice independent scalability and deployment
  • Distributed architectures: Gain those benefits but pay transport costs
  • The optimal choice depends on whether the operational flexibility justifies the ongoing transport expense

Particular Impact on Specific Domains:

  • Edge computing: Edge devices on metered cellular connections pay per megabyte transmitted
  • IoT systems: IoT devices on battery power must minimize radio transmission to preserve energy—transport costs battery life
  • Global architectures: Systems spanning multiple cloud regions or providers must carefully manage where data flows to minimize inter-region and egress charges

Influences Technology Choices: Transport cost considerations become decision criteria for architecturally significant decisions:

  • REST APIs with verbose JSON payloads cost more to transport than compact binary protocols
  • GraphQL’s ability to request only needed fields reduces payload sizes compared to REST’s full-entity responses
  • gRPC with Protocol Buffers offers lower transport costs than traditional REST with JSON

Sources

  • Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.

  • Deutsch, Peter (1994-1997). “The Eight Fallacies of Distributed Computing.” Originally articulated at Sun Microsystems.

    • Seventh fallacy in the original list
    • Identified through observing hidden costs in distributed system design
    • Widely referenced in distributed systems literature

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks