6 ms·

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

144 points by teleforce 4mo ago

jrpelkonen 4mo ago
In this instance latency must’ve been 10 years, per my memory this paper came out in 1994
- rusk 4mo ago
  According to Wikipedia it was first shown to Scott McNeally, but according to Deutsch himself it was more like 92…
zephen 4mo ago
On the one hand, the list isn't wrong. On the other hand, more fortunes have been made by assuming that physics will catch up (closely enough, anyway) to computational needs, than by assuming that every byte and every cycle and every nanosecond matters.
- shermantanktop 4mo ago
  Making money and being highly available are different goals.
  - rusk 4mo ago
    Stock markets and commercial Telecomms beg to differ
    - inigyou 4mo ago
      Is every business a stock market and commercial Telecomm?
      - rusk 4mo ago
        > Making money and being highly available are different goals. These are large, highly profitable vertical markets. The above remark is demonstrably foolish and ignorant.
        shermantanktop 4mo ago
        Can you make money without being highly available? Can you be highly available without making money? And btw I've worked in both the industries you cite. It's hard to think of telecomms having amazing uptime when you have to write a restart script for a core security daemon because the sysadmin doesn't know how.
        rusk 4mo ago
        [flagged]
        IAmBroom 4mo ago
        OK, fine: Making money and being highly available often different goals.
        rusk 4mo ago
        Not if being highly available is central to your business model which is about half the industry
      - saltcured 4mo ago
        Asymptotically, every billing system is a stock market and telecom. ;-) My biggest career horror was realizing how much the medical informatics concepts have been structured around billing and insurance rather than scientific, biomedical requirements.
- inigyou 4mo ago
  In 2026 Moore's law has mostly stopped. My computer from 10 years ago still has acceptable performance today. My computer from 15 years ago would struggle a bit but still get the job done. This is nothing like the 90s where you actually could wait two years for all of that year's conceivable performance problems to be solved.
  - neonstatic 4mo ago
    [dead]
  - gf000 4mo ago
    Dennard scaling has stopped (performance/clock speed increasing), Moore's law means mostly transistor count or density. The former is still going strong, the latter is slowing down.
- RetroTechie 4mo ago
  That's like saying money is only spent on sw/hw systems which rely on ever-growing compute capacity. Reality: embedded systems are a thing. And there's (lots of!) money in that business too. There's maaaany applications where some (fixed) amount of compute does the job, and the simplest/cheapest device that does it wins out.
  - zephen 4mo ago
    > Reality: embedded systems are a thing. I've worked in embedded, and chips, and embedded chips for most of my career. > There's maaaany applications where some (fixed) amount of compute does the job, and the simplest/cheapest device that does it wins out. There's usually quite a bit factored in for slop in these days, because time-to-market is a thing. There's also sometimes a cost-reduction stage (yeah, I've been involved in cost reductions where a penny a unit was awesome), but you don't bother doing the cost-reduction phase unless you have the volume to support it. Warren Buffet famously said that "Concentration builds wealth, diversification preserves it." In much of computing, even embedded, demos and prototypes build a product, and the right-sizing of everything to make it even more profitable happens later, if it is worth it.
randfur 4mo ago
Do people actually believe these dot points or are they just out of scope for most applications to tackle beyond letting the user try again?
- rusk 4mo ago
  Perfect demonstration of the fallacies in action! If you were used to developing applications on a self contained platform you would think something like “sure, if it fails the user can try again” On a distributed system the user can only try again if the platform has remained stable, the failure is transient (*) and they have (crucially) have been given the information to retry. The platform that provides a stable environment for the user to just try again has been built on these principles. (*) there is one administrator assumes it is within the user’s power to resolve the issue
  - Nicook 4mo ago
    >we'll just add this feature on as some async verification since it takes a while, then make the original update wait in some weird state for it to finish. Later, when users are confused at failures and weird states. >ok now lets build a new system that tries to gather all this information on updates in "weird states" and let users fix them! simplified example, but nightmare.
    - rusk 4mo ago
      If you’re exposing system concerns mixed in with application code you’re either doing it wrong or using some outdated architecture. Either way, it’s no excuses for shipping slop, which is what you’ve done it your software only works under limited idealised circumstances TFA is for you
- chasil 4mo ago
  I have had a developer with anger issues expect 100% success with FTP file transfers, and anything that failed was 100% my fault as a Linux/Oracle administrator. These FTP sessions were running over WANs connecting Pennsylvania, Iowa, and Tennessee. I ended up writing him an "until curl ftp://...; do echo it failed again; done" loop which calmed that particular issue down. I don't miss that guy, not even 1%. Good riddance.
rusk 4mo ago
This article reiterates a lot of the Wikipedia stuff, while contradicting the main extant source which is Deutsch himself (https://se-radio.net/2021/07/episode-470-l-peter-deutsch-on-the-fallacies-of-distributed-computing/ https://se-radio.net/2021/07/episode-470-l-peter-deutsch-on-...). Nobody really knows who wrote the first four fallacies. They were just floating around it is Deutsch who pinned them down and it was Gosling’s endorsement that made them into the shibboleth that they are.
- stonogo 4mo ago
  Deutsch speculated it was "either Bill or Dick Lyon" (sic) (https://web.archive.org/web/20040203202935/http://www.aladdin.com/users/ghost/ https://web.archive.org/web/20040203202935/http://www.aladdi...) but there has been speculation he meant Tom Lyon, who worked there at the time. Gosling had them hosted on his website for a long time (https://web.archive.org/web/20021206065457/http://java.sun.com/people/jag/Fallacies.html https://web.archive.org/web/20021206065457/http://java.sun.c...)
  - rusk 4mo ago
    Yes, he didn’t really know. So the original attribution is fuzzy Gosling still has them on his present day site https://nighthacks.com/jag/blog/401/index.html https://nighthacks.com/jag/blog/401/index.html
aussieguy1234 4mo ago
This is highly relevant to the recent craze over microservices, which has settled down now (after un-neccasarily complicating systems at multiple companies).
- rusk 4mo ago
  Micoserices or Monolith. It’s like being caught between the devil and the deep blue see. It’s a pity domain sockets never took off but I guess TCP/IP is the only truly cross platform IPC mechanism …
  - inigyou 4mo ago
    Aren't Windows's named pipes very similar?
    - rusk 4mo ago
      I believe so. I don’t think either that or domain sockets are quite as ubiquitous as TCP sockets though. The issue I see with domain sockets is that although they may be supported for example by spring, you can’t rely on a consistent cross platform experience which is perhaps (anachronistically?) a core ethic of the Java community. I would favour domain sockets as to make a component go from being embedded to networked would require a small but significant implementation step. But established best practice unfortunately disagrees with me.
      - inigyou 4mo ago
        The more interesting thing on Windows would actually be COM, which is something like Java interfaces but for native code, that are optionally cross-process.
        rusk 4mo ago
        In my recollection COM became ActiveX which fell down the distributed objects hole along with CORBA because it embodied many of these fallacies.
jffhn 4mo ago
Also, the four fallacies of local computing: - The CPU is infinitely fast. - RAM is infinite. - CPU caches don't exist. - Cache lines don't exist.
- necovek 4mo ago
  Disk never gets filled up.
- mojuba 4mo ago
  - The computer is plugged to an infinite source of unlimited power This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
  - gf000 4mo ago
    Java is basically the "greenest" managed language out there, so not sure putting it into the same list for energy efficiency is warranted. Though of course energy efficiency is fundamentally linked to memory usage, not destructing/collecting dead objects will increase memory usage but increase efficiency. https://www.sciencedirect.com/science/article/pii/S0167642321000022 https://www.sciencedirect.com/science/article/pii/S016764232...
    - rusk 4mo ago
      Indeed, the Java mobile platform had power consciousness baked in 25 or so years ago.
    - kator 4mo ago
      Reading your link IMHO in today's world I would set a basic rule, if you're touching >20% of a Java codebase you should refactor to Rust. With AI-Native development practices it's worth the SDE time to refactor, replace the underlying subsytem and reduce your fleet by 50% or more.
mrkeen 4mo ago
A couple more that don't seem to be represented there. No mention of cause and effect, or the order in which different nodes perceive things happening? Anyway here's three which I think might be more relevant to designing and building software: * Your system is not a distributed system Multiple users connect, disconnect, and use your system at the same time, some of the code is running on your servers, some of it's in your partners' servers, some of it's in your storage layer, and some of it's running on your users' computers * Your DB's ACID transactions are sufficient for distributed thinking An ACID transaction lets you addUser() to your storage, either succeeding completely or failing completely, with no observable intermediate state. It does not let both your frontend and your storage layer addUser(), same with both your storage and your partner's storage. * Your DB's transactions are ACID Your DB vendors cannot build databases that are acceptably fast while running ACID. Therefore isolation is relaxed and transactions can commit through each other. Even if the DB itself was ACID, your ORM and/or programming style is likely breaking ACID independently of the DB configuration.
- rusk 4mo ago
  > No mention of cause and effect, or the order in which different nodes perceive things happening? 8. The network is homogeneous Often misconstrued as a recapitulation of “there is one administrator” A homogenous system, such as a single node Java application, for instance usually provides very clear semantics for this.
- anax32 4mo ago
  * You will have logs Always gets me
- bayindirh 4mo ago
  Another one from my experience: * Hardware is cheap. So many services and daemons are running on your system and most of them believe that they have all the hardware for themselves, while the opposite is true. Designing to capitalize whole hardware while they are other processes which are fighting to do the same never ends well. OTOH, being a good citizen on a crowded system makes life for everyone better. Both maintenance and performance-wise.
master_crab 4mo ago
There needs to be a distinction - because people are making an honest conflation - between distributed computing and cloud computing. The list in the article applies to both, but the limits and performance variability can apply quicker - and with more effect - in the cloud.
duxup 4mo ago
When I worked with high end networking equipment latency, bandwidth, jitter and bursty traffic was just a never ending conversation…

144 points by teleforce 4mo ago

jrpelkonen 4mo ago

In this instance latency must’ve been 10 years, per my memory this paper came out in 1994

rusk 4mo ago
According to Wikipedia it was first shown to Scott McNeally, but according to Deutsch himself it was more like 92…

zephen 4mo ago

On the one hand, the list isn't wrong. On the other hand, more fortunes have been made by assuming that physics will catch up (closely enough, anyway) to computational needs, than by assuming that every byte and every cycle and every nanosecond matters.

shermantanktop 4mo ago
Making money and being highly available are different goals.
- rusk 4mo ago
  Stock markets and commercial Telecomms beg to differ
  - inigyou 4mo ago
    Is every business a stock market and commercial Telecomm?
    - rusk 4mo ago
      > Making money and being highly available are different goals. These are large, highly profitable vertical markets. The above remark is demonstrably foolish and ignorant.
      - shermantanktop 4mo ago
        Can you make money without being highly available? Can you be highly available without making money? And btw I've worked in both the industries you cite. It's hard to think of telecomms having amazing uptime when you have to write a restart script for a core security daemon because the sysadmin doesn't know how.
        rusk 4mo ago
        [flagged]
      - IAmBroom 4mo ago
        OK, fine: Making money and being highly available often different goals.
        rusk 4mo ago
        Not if being highly available is central to your business model which is about half the industry
    - saltcured 4mo ago
      Asymptotically, every billing system is a stock market and telecom. ;-) My biggest career horror was realizing how much the medical informatics concepts have been structured around billing and insurance rather than scientific, biomedical requirements.
inigyou 4mo ago
In 2026 Moore's law has mostly stopped. My computer from 10 years ago still has acceptable performance today. My computer from 15 years ago would struggle a bit but still get the job done. This is nothing like the 90s where you actually could wait two years for all of that year's conceivable performance problems to be solved.
- neonstatic 4mo ago
  [dead]
- gf000 4mo ago
  Dennard scaling has stopped (performance/clock speed increasing), Moore's law means mostly transistor count or density. The former is still going strong, the latter is slowing down.
RetroTechie 4mo ago
That's like saying money is only spent on sw/hw systems which rely on ever-growing compute capacity. Reality: embedded systems are a thing. And there's (lots of!) money in that business too. There's maaaany applications where some (fixed) amount of compute does the job, and the simplest/cheapest device that does it wins out.
- zephen 4mo ago
  > Reality: embedded systems are a thing. I've worked in embedded, and chips, and embedded chips for most of my career. > There's maaaany applications where some (fixed) amount of compute does the job, and the simplest/cheapest device that does it wins out. There's usually quite a bit factored in for slop in these days, because time-to-market is a thing. There's also sometimes a cost-reduction stage (yeah, I've been involved in cost reductions where a penny a unit was awesome), but you don't bother doing the cost-reduction phase unless you have the volume to support it. Warren Buffet famously said that "Concentration builds wealth, diversification preserves it." In much of computing, even embedded, demos and prototypes build a product, and the right-sizing of everything to make it even more profitable happens later, if it is worth it.

randfur 4mo ago

Do people actually believe these dot points or are they just out of scope for most applications to tackle beyond letting the user try again?

rusk 4mo ago
Perfect demonstration of the fallacies in action! If you were used to developing applications on a self contained platform you would think something like “sure, if it fails the user can try again” On a distributed system the user can only try again if the platform has remained stable, the failure is transient (*) and they have (crucially) have been given the information to retry. The platform that provides a stable environment for the user to just try again has been built on these principles. (*) there is one administrator assumes it is within the user’s power to resolve the issue
- Nicook 4mo ago
  >we'll just add this feature on as some async verification since it takes a while, then make the original update wait in some weird state for it to finish. Later, when users are confused at failures and weird states. >ok now lets build a new system that tries to gather all this information on updates in "weird states" and let users fix them! simplified example, but nightmare.
  - rusk 4mo ago
    If you’re exposing system concerns mixed in with application code you’re either doing it wrong or using some outdated architecture. Either way, it’s no excuses for shipping slop, which is what you’ve done it your software only works under limited idealised circumstances TFA is for you
chasil 4mo ago
I have had a developer with anger issues expect 100% success with FTP file transfers, and anything that failed was 100% my fault as a Linux/Oracle administrator. These FTP sessions were running over WANs connecting Pennsylvania, Iowa, and Tennessee. I ended up writing him an "until curl ftp://...; do echo it failed again; done" loop which calmed that particular issue down. I don't miss that guy, not even 1%. Good riddance.

rusk 4mo ago

This article reiterates a lot of the Wikipedia stuff, while contradicting the main extant source which is Deutsch himself (https://se-radio.net/2021/07/episode-470-l-peter-deutsch-on-the-fallacies-of-distributed-computing/ https://se-radio.net/2021/07/episode-470-l-peter-deutsch-on-...). Nobody really knows who wrote the first four fallacies. They were just floating around it is Deutsch who pinned them down and it was Gosling’s endorsement that made them into the shibboleth that they are.

stonogo 4mo ago
Deutsch speculated it was "either Bill or Dick Lyon" (sic) (https://web.archive.org/web/20040203202935/http://www.aladdin.com/users/ghost/ https://web.archive.org/web/20040203202935/http://www.aladdi...) but there has been speculation he meant Tom Lyon, who worked there at the time. Gosling had them hosted on his website for a long time (https://web.archive.org/web/20021206065457/http://java.sun.com/people/jag/Fallacies.html https://web.archive.org/web/20021206065457/http://java.sun.c...)
- rusk 4mo ago
  Yes, he didn’t really know. So the original attribution is fuzzy Gosling still has them on his present day site https://nighthacks.com/jag/blog/401/index.html https://nighthacks.com/jag/blog/401/index.html

aussieguy1234 4mo ago

This is highly relevant to the recent craze over microservices, which has settled down now (after un-neccasarily complicating systems at multiple companies).

rusk 4mo ago
Micoserices or Monolith. It’s like being caught between the devil and the deep blue see. It’s a pity domain sockets never took off but I guess TCP/IP is the only truly cross platform IPC mechanism …
- inigyou 4mo ago
  Aren't Windows's named pipes very similar?
  - rusk 4mo ago
    I believe so. I don’t think either that or domain sockets are quite as ubiquitous as TCP sockets though. The issue I see with domain sockets is that although they may be supported for example by spring, you can’t rely on a consistent cross platform experience which is perhaps (anachronistically?) a core ethic of the Java community. I would favour domain sockets as to make a component go from being embedded to networked would require a small but significant implementation step. But established best practice unfortunately disagrees with me.
    - inigyou 4mo ago
      The more interesting thing on Windows would actually be COM, which is something like Java interfaces but for native code, that are optionally cross-process.
      - rusk 4mo ago
        In my recollection COM became ActiveX which fell down the distributed objects hole along with CORBA because it embodied many of these fallacies.

jffhn 4mo ago

Also, the four fallacies of local computing: - The CPU is infinitely fast. - RAM is infinite. - CPU caches don't exist. - Cache lines don't exist.

necovek 4mo ago
Disk never gets filled up.
mojuba 4mo ago
- The computer is plugged to an infinite source of unlimited power This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
- gf000 4mo ago
  Java is basically the "greenest" managed language out there, so not sure putting it into the same list for energy efficiency is warranted. Though of course energy efficiency is fundamentally linked to memory usage, not destructing/collecting dead objects will increase memory usage but increase efficiency. https://www.sciencedirect.com/science/article/pii/S0167642321000022 https://www.sciencedirect.com/science/article/pii/S016764232...
  - rusk 4mo ago
    Indeed, the Java mobile platform had power consciousness baked in 25 or so years ago.
  - kator 4mo ago
    Reading your link IMHO in today's world I would set a basic rule, if you're touching >20% of a Java codebase you should refactor to Rust. With AI-Native development practices it's worth the SDE time to refactor, replace the underlying subsytem and reduce your fleet by 50% or more.

mrkeen 4mo ago

A couple more that don't seem to be represented there. No mention of cause and effect, or the order in which different nodes perceive things happening? Anyway here's three which I think might be more relevant to designing and building software: * Your system is not a distributed system Multiple users connect, disconnect, and use your system at the same time, some of the code is running on your servers, some of it's in your partners' servers, some of it's in your storage layer, and some of it's running on your users' computers * Your DB's ACID transactions are sufficient for distributed thinking An ACID transaction lets you addUser() to your storage, either succeeding completely or failing completely, with no observable intermediate state. It does not let both your frontend and your storage layer addUser(), same with both your storage and your partner's storage. * Your DB's transactions are ACID Your DB vendors cannot build databases that are acceptably fast while running ACID. Therefore isolation is relaxed and transactions can commit through each other. Even if the DB itself was ACID, your ORM and/or programming style is likely breaking ACID independently of the DB configuration.

rusk 4mo ago
> No mention of cause and effect, or the order in which different nodes perceive things happening? 8. The network is homogeneous Often misconstrued as a recapitulation of “there is one administrator” A homogenous system, such as a single node Java application, for instance usually provides very clear semantics for this.
anax32 4mo ago
* You will have logs Always gets me
bayindirh 4mo ago
Another one from my experience: * Hardware is cheap. So many services and daemons are running on your system and most of them believe that they have all the hardware for themselves, while the opposite is true. Designing to capitalize whole hardware while they are other processes which are fighting to do the same never ends well. OTOH, being a good citizen on a crowded system makes life for everyone better. Both maintenance and performance-wise.

master_crab 4mo ago

There needs to be a distinction - because people are making an honest conflation - between distributed computing and cloud computing. The list in the article applies to both, but the limits and performance variability can apply quicker - and with more effect - in the cloud.

duxup 4mo ago

When I worked with high end networking equipment latency, bandwidth, jitter and bursty traffic was just a never ending conversation…