21 years and counting of 'eight fallacies of distributed computing' (2025)

The useful addition was not whether the list is still true. It plainly is. The sharper point was that people keep mis-scoping what counts as “distributed.” Several commenters argued that many teams think they are building a simple app when they are already in distributed-systems territory because the browser, app server, database, partner APIs, background jobs, and storage layer all see different states at different times. That is why “just let the user retry” is not a serious strategy by itself. Retries only work if the platform preserves enough state, exposes the right error information, and makes repeated actions safe. A second theme was that today’s cloud and microservice habits make the old fallacies easier to trigger, not less relevant. The list applies to any multi-node system, but cloud infrastructure adds more performance variance and more administrative boundaries. Commenters tied that directly to the microservices boom. Splitting one process into many services turns local calls into network calls, imports latency and partial failure into ordinary product flows, and forces teams to care about ordering, idempotency, and degraded states much earlier. People also stretched the idea beyond networks. One of the most upvoted riffs was a set of “local computing fallacies” like assuming infinite CPU, RAM, and invisible cache behavior. That line landed because modern developers often inherit powerful machines and managed runtimes, which hides hardware limits until cost, scale, or AI workloads bring them back with force. The broad takeaway was that the original fallacies aged well because they name a deeper habit. Engineers optimize for the happy path, then act surprised when physical limits, shared infrastructure, and mismatched failure domains reassert themselves.