Fallacies of Distributed Computing: 1. The network is reliable
Tags: distributedcomputing
Published: 2020-04-20 00:00:00

---
title: "Fallacies of Distributed Computing: 1. The network is reliable"
date: "2020-04-20T00:00:00.000Z"
tags: ["distributedcomputing"]
---

[The fallacies of distributed computing](https://web.archive.org/web/20171107014323/http://blog.fogcreek.com/eight-fallacies-of-distributed-computing-tech-talk/) are a set of assertions describing false assumptions made about distributed systems. 

[L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) drafted the first 7 fallacies in 1994, with the 8<sup>th</sup> added by [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) in 1997.

The 8 fallacies are:

1. [The network is reliable](https://dereklawless.ie/fallacies-of-distributed-computing-1-the-network-is-reliable)
1. [Latency is zero](https://dereklawless.ie/fallacies-of-distributed-computing-2-latency-is-zero)
1. [Bandwidth is infinite](https://dereklawless.ie/fallacies-of-distributed-computing-3-bandwidth-is-infinite)
1. [The network is secure](https://dereklawless.ie/fallacies-of-distributed-computing-4-the-network-is-secure)
1. [Topology doesn't change](https://dereklawless.ie/fallacies-of-distributed-computing-5-topology-doesnt-change)
1. [There is one administrator](https://dereklawless.ie/fallacies-of-distributed-computing-6-there-is-one-administrator)
1. [Transport cost is zero](https://dereklawless.ie/fallacies-of-distributed-computing-7-transport-cost-is-zero)
1. [The network is homogeneous](https://dereklawless.ie/fallacies-of-distributed-computing-8-the-network-is-homogeneous)

## 1. The network is reliable

### The problem

Many systems are interconnected in nature, that is to say in normal execution they may make calls to other systems over one or more networks to satisfy functionality requirements.

In any tiered architecture the underlying process and mechanism of communication will be (hopefully) abstracted away - for example taking a payment on behalf of a customer may be as straightforward as calling a method like so:

~~~csharp
var svc = new PaymentService();
svc.takePayment(paymentRequest);
~~~

This level of abstraction is both useful and desirable, however it does tend to pre-dispose our view towards success. What happens when an underlying network call to a third-party payments processor fails with e.g an HTTP timeout exception?

Depending on _when_ and _how_ such an error occurs, the request may be retryable without adverse side effect(s). However, for any retry to be deterministic in the affirmative the system must be indempotent. Without indempotence, retrying the above request _N times_ may result in the customer being charged _N times_.

A network may be unreliable for any number of reasons:

- A software issue
- A hardware issue
- A security issue
- An environmental issue
- A bad actor e.g. a _Denial of Service_ attack
- A combination of any or all of the above

A system architected for resiliance and correctness must consider the above factors in its design.

### A solution

To mitigate network unreliability, a __Retry and Acknowledgement__ design can be leveraged using a queuing system. 

Queuing systems typically implement a pattern known as _Store and Forward_ - they store the message locally and then forward it to the recipient(s). If forwarding fails, the queuing system will retry automatically. If failure persists past a specified number of attempts, the message will be moved to a [Dead Letter Queue](https://en.wikipedia.org/wiki/Dead_letter_queue). The message is considered undelivered until the queue receives an acknowledgement of receipt from the recipient.

> Implementing queuing requires moving from a synchronous request/response centric model to an ansychronous one. This is - typically - not a trivial excercise in a system of any complexity and may require re-evaluation of other aspects of your system, not least user experience.