Why Distributed Systems Are Often Slower Than One Laptop

In 2015, Frank McSherry, Michael Isard and Derek Murray published 'Scalability! But at What COST?', comparing leading distributed graph-processing systems against a single-threaded laptop. The results were stark: finding connected components in Twitter's follower graph took GraphLab 242 seconds on 128 cores, while a single thread using a 1970s union-find algorithm finished in 15. The paper formalized this as the COST metric — the number of cores a distributed system needs before it beats one competent thread. For many systems that number ran into the hundreds; for some it was never reached at all.

A worked example shows what this costs today. A SaaS company processing 2 billion events daily runs a Kafka-and-Flink pipeline costing roughly $1.4 million a year in compute, platform engineering, and coordination-related incidents. Yet the actual workload — about 12 megabytes per second — fits comfortably within a single modern server's capacity. Two redundant machines and a fraction of one engineer's time could handle the same load for about $57,000 a year, and faster, since the overhead of packing and shipping data across a network disappears entirely.

This reflex made sense between 2004 and 2012, when Google's MapReduce era genuinely required spreading jobs across many machines. Hardware has since advanced roughly a hundredfold — single servers now offer 192 cores and terabytes of memory — while most companies' actual data volumes remain under a terabyte. Amazon's Prime Video team cut costs by 90% after consolidating microservices into a single program, and similar simplifications at Segment and Stack Overflow reinforced the pattern.

The core issue is that this comparison is rarely made: distributed systems are benchmarked against other distributed systems, never against a single-machine baseline. For engineers, the lesson is clear — without measuring real workload size first, adopting distributed architecture by default often means paying heavily just to parallelize your own coordination overhead.