The Eight Fallacies of Distributed Computing are a set of assumptions that developers make while designing Distributed Systems which might backfire and cause additional work and system redesign in the long run. In 1994, Peter Deutsch, a sun fellow at the time, drafted 7 assumptions architects and designers of distributed systems are likely to make, which prove wrong in the long run - resulting in all sorts of troubles and pains for the solution and architects who made the assumptions. In 1997 James Gosling added another such fallacy. The assumptions are now collectively known as the The 8 fallacies of distributed computing.

1. The Network is Reliable

The network is unreliable and we as software architect/designers need to address that.
Why is this a fallacy? Well, when was the last time you saw a switch fail? After all, even basic switches these days have MTBFs (Mean Time Between Failure) in the 50,000 operating hours and more. The situation is more complicated if you collaborate with an external partner, such as an e-commerce application working with an external credit-card processing service. Their side of the connection is not under your direct control. Lastly there are security threats like DDOS attacks and the like.
Solution
  • Automatic Retries
  • Message Queues

2. Latency is Zero

Latency is how much time it takes for data to move from one place to another.
Latency can be relatively good on a LAN, but latency deteriorates quickly when you move to WAN scenarios or internet scenarios. Wrong assumptions about latency/distribution can cause significant performance issue in a system.
Solution
    • Co-locate chatty components
    • Batch Requests - Include multiple request in meta request payload and server will send meta response
    • Carry all required data in request payload
    • Caching Strategy
    • Deploy in AZs near client

3. Bandwidth is infinite

This fallacy, in my opinion, is not as strong as the others. If there is one thing that is constantly getting better in relation to networks it is bandwidth.
The main implication then is to consider that in the production environment of our application there may be bandwidth problems which are beyond our control and we should bear in mind how much data is expected to travel over the wire.
Solution
  • Throttling Policy
  • Small Payloads with Micro-services

4. The Network is Secure

The only system that is completely secure is one that does not connected to network.
As an architect you might not be a security expert - but you still need to be aware that security is needed and the implications it may have.
Solution
  • Network Firewalls
  • Encryption
  • Certificates
  • Authentication

5. Topology doesn’t change

Topology doesn't change. That's right?, it doesn’t -- as long as it stays in the test lab.
When you're talking about clients, the situation is even worse. There are laptops coming and going, wireless ad-hoc networks, new mobile devices. In short, topology is changing constantly.
Solution
We need to build a Service discovery, so that clients of service can figure out, how to reach particular service.

6. There is one administrator

You may be able to get away with this fallacy if you install your software on small, isolated LANs (for instance, a single person IT group with no WAN/Internet). However, for most enterprise systems the reality is much different.
When there is more than one administrator, you need to remember that administrators can constrain your options (administrators that sets disk quotas, limited privileges, limited ports and protocols and so on), and that you need to help them manage your applications.
Solution
DevOps Culture eliminates Bus Factor

7. Transport cost is zero

The cost of setting & running the network infrastructure
Application level to the transport level needs marshaling (serialize information into bits) to get data unto the wire, which takes both computer resources and adds to the latency.
Solution
Standardized protocols like JSON, Cost Calculation

8. The network is homogeneous

This fallacy is added by the James Gosling.
Any network except maybe the very trivial ones, are not homogeneous.
The network is not smooth pipe, rather it consist of various legs or miles with very different characteristics.
Solution
  • Circuit Breaker
  • Retry and Timeout Design Pattern

Final Thought

More than 40 years since we started building distributed systems – the characteristics and underlying problems of distributed systems remain pretty much the same. What is more alarming is that architects, designers and developers are still tempted to wave some of these problems off thinking technology solves everything.
Designing Distributed Systems is challenging and being aware of these eight fallacies will help us in batter system design.