Fallacies of Distributed Computing: 2. Latency is zero
Tags: distributedcomputing
Published: 2020-04-22 00:00:00

---
title: "Fallacies of Distributed Computing: 2. Latency is zero"
date: "2020-04-22T00: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)

## 2. Latency is zero

### The problem

[Latency](https://en.wikipedia.org/wiki/Latency_(engineering)) is defined as the time interval between a stimulus and the corresponding response. In network terms, it's the amount of time required to move data from one location to another. __Network traffic is not instant.__

At one time remote objects were seen as a desirable design objective, encapsulating local or remote implementation details and allowing for so-called network transparency. For example:

~~~csharp
// C#
var user = new User(1);
user.Password = "Password1";
~~~

The above operation may simply set the password on a `User` instance in memory or it may also initiate one or more remote calls to update a user password in a database, the implications are opaque.

Thankfully, the use of remote objects is, by and large, frowned upon these days in favour of other techniques such as <abbr title="Data Transfer Objects">DTOs</abbr> which provide greater transparency. (It is always worth formalising the segregation of local and remote calls through effective application of appropriate design patterns.)

One technique frequently used with <abbr title="Object Relational Mapping">ORM</abbr> technologies is deferred, or lazy, loading. With deferred loading, data is retrieved only when needed rather than prefetched. 

A typical example might entail retrieving the orders and order line items associated with a customer account:

~~~csharp
// C#
var svc = new OrderService();
var orders = svc.GetOrdersForCustomer(1); // Returns an IQueryable<Order>, deferred

foreach (var order in orders.ToList()) { // Enumerated, call
	var items = order.GetItems(); // Returns an IQueryable<OrderLineItem>, deferred
	// ...
}
~~~

Here, rather than fetching all the customer orders and associated line items in one call, the orders will be fetched when enumerated with the corresponding order line items also fetched on first use. This is a classic example of an unintended `SELECT N + 1` query, resulting in multiple remote calls to the database or service providing the data.

### Solutions

#### Reduce the number of remote calls

Given each remote call made will be several orders of magnitude slower than a local equivalent, you should design with the objective of optimising the number of remote calls. One way to achieve this by designing payloads to __include all the data you might need__ to support a particular use case, removing the likelihood (or need) of additional remote calls to fetch data at more granular levels.

#### Locate the data closer to the client

As latency is ultimately a physics problem, locating data closer to the geographic location of the client will facilitate reduced latency (all other network factors being equal). All public cloud infrastructure providers such as <abbr title="Amazon Web Services">AWS</abbr>, Azure, or <abbr title="Google Cloud Platform">GCP</abbr> support deployment into multiple availability zones.

#### Caching

Caching should also be implemented wherever possible to reduce unnecessary remote calls.