Your Distributed System Is Slower Than a Laptop, CodeGood

5 July 2026

Your Distributed System Is Slower Than a Laptop

Why companies pay millions to parallelise their own overhead

In 2015, three researchers, Frank McSherry, Michael Isard and Derek Murray, published a short paper with a title that should have ended several product roadmaps: “Scalability! But at what COST?” Their test was simple. They took the published benchmarks from the leading distributed graph-processing systems, the kind that spread one computation across hundreds of cores, and ran the same workloads on a single thread of McSherry’s laptop.

The laptop won. Not narrowly, and not on toy problems. One task was finding connected components in Twitter’s follower graph: 1.5 billion follow relationships, with the job of working out which accounts link to which. GraphLab, a leading system of the day, took 242 seconds using 128 cores. The laptop, running a simple technique from the 1970s called union-find, finished in 15. PageRank, the algorithm Google originally used to rank web pages, told the same story. The single thread completed 20 iterations in 300 seconds, or 110 with a better memory layout. GraphX needed 128 cores to take 419.

The paper turned this into a metric: COST, the Configuration that Outperforms a Single Thread. In plain terms, how many cores does a distributed system need before it beats one competent thread on one machine? For several published systems the answer was in the hundreds. For some the authors recorded it as unbounded: no configuration of any size ever caught up.

That paper is a decade old. It has been cited, admired, and almost entirely ignored. Distributed systems are supposed to trade simplicity for performance: you accept complexity and get speed in return. Measured, they often trade away both, and send the bill to the infrastructure budget. One worked example shows the size of the bill.

A $1.4 million system doing a $57,000 job

Consider a mid-market SaaS company with 55 engineers. Its event pipeline handles 2 billion events a day: clicks, telemetry, billing signals. The architecture is the standard one. A Kafka cluster of nine machines queues the events; a Flink deployment of 128 virtual CPUs processes them; a fleet of smaller services consumes the results. (Kafka and Flink are the industry’s default tools for moving and processing streams of events. A virtual CPU is one rented core.) Three and a half platform engineers keep it all alive. The design passed review without argument, because every component is an industry standard.

Now do the division. Two billion events a day is 23,000 events per second. At 500 bytes per event, the daily volume is one terabyte, which works out at 12 megabytes per second. For scale: one modern solid-state drive reads 7,000 megabytes per second, and one core can parse several hundred thousand small JSON records per second. This is a single-machine workload with a hundredfold margin to spare at peak.

What the company pays to treat it as a distributed one:

Compute. 128 virtual CPUs of stream processing at $0.10 per core-hour, running around the clock: $112,000 a year. The Kafka machines, with their storage and replication: roughly $90,000. Then cross-zone transfer, the charge cloud providers levy when data moves between their data centres. An event pipeline that replicates everything moves a great deal of data between data centres: another $60,000.

People. The platform engineers exist because the architecture exists. Queues need rebalancing; checkpoints need tuning; lagging consumers need watching; message formats need governing. At a loaded cost of $250,000 per engineer, 3.5 of them cost $875,000 a year. This is the largest number in the system and the least examined, because it is booked as headcount rather than infrastructure.

Incidents. Systems built from many coordinating parts fail in coordination-specific ways. A queue rebalances itself in the middle of a deploy. A checkpoint corrupts. A system that promises to process each event exactly once will, under failure, process some events twice. One serious incident a quarter, at $60,000 in engineering time and customer clean-up, is a conservative rate: $240,000 a year.

The comparison nobody priced. Two servers at $10,000 each, a primary and a spare, spread over three years, plus a fifth of one engineer to own the ingest process: about $57,000 a year. And the single process is faster, not merely cheaper. The work of packing data up, sending it across the network and unpacking it again, the work that consumed most of the cluster’s cores, is simply gone. This is the detail the scaling chart never shows. The distributed version is not a faster system that costs more; it is usually a slower system that costs more.

Cost categoryDistributedSingle machine

Compute and network$262,000$7,000<br>Platform engineering$875,000$50,000<br>Incident burden$240,000minimal<br>Annual total $1,377,000...