Beginner's Mind

Software is not limited by physics, like buildings are.

It is limited by imagination, by design, by organization.

In short, it is limited by properties of people, not by properties of the world.

“We have met the enemy, and he is us.”

PACELC

A more complete portrayal of the space of potential consistency tradeoffs for DDBSs can be achieved by rewriting CAP as PACELC (pronounced “pass-elk”):

• if there is a partition (P), how does the system trade off availability and consistency (A and C);
• else (E), when the system is running normally in the absence of partitions, how does the system trade off latency (L) and consistency (C)?

Note that the latency/consistency tradeoff (ELC) only applies to systems that replicate data. Otherwise, the system suffers from availability issues upon any type of failure or overloaded node. Because such issues are just instances of extreme latency, the latency part of the ELC tradeoff can incorporate the choice of whether or not to replicate data.

The default versions of Dynamo, Cassandra, and Riak are PA/EL systems: if a partition occurs, they give up consistency for availability, and under normal operation they give up consistency for lower latency. (…)

Fully ACID systems such as VoltDB/H-Store and Megastore are PC/EC: they refuse to give up consistency, and will pay the availability and latency costs to achieve it. BigTable and related systems such as HBase are also PC/EC.

MongoDB can be classified as a PA/EC system. In the baseline case, the system guarantees reads and writes to be consistent. (…)

PNUTS is a PC/EL system. In normal operation, it gives up consistency for latency; however, if a partition occurs, it trades availability for consistency. (…)

Note that availability and latency are arguably the same thing: an unavailable system essentially provides extremely high latency.

(…) I consider systems with latencies larger than a typical request timeout, such as a few seconds, as unavailable, and latencies smaller than a request timeout, but still approaching hundreds of milliseconds, as “high latency.”

It is not merely the partition tolerance that necessitates a tradeoff between consistency and availability; rather, it is the combination of

• partition tolerance and
• the existence of a network partition itself

The theorem simply states that a network partition causes the system to have to decide between reducing availability or consistency.

The probability of a network partition is highly dependent on the various details of the system implementation:

• Is it distributed over a wide area network (WAN), or just a local cluster?
• What is the quality of the hardware?
• What processes are in place to ensure that changes to network configuration parameters are performed carefully?
• What is the level of redundancy?

Nonetheless, in general, network partitions are somewhat rare, and are often less frequent than other serious types of failure events in DDBSs.

As CAP imposes no system restrictions in the baseline case, it is wrong to assume that DDBSs that reduce consistency in the absence of any partitions are doing so due to CAP-based decision-making.

In fact, CAP allows the system to make the complete set of ACID (atomicity, consistency, isolation, and durability) guarantees alongside high availability when there are no partitions.

Therefore, the theorem does not completely justify the default configuration of DDBSs that reduce consistency (and usually several other ACID guarantees).

Writing Testable Code

Warning Signs

• new keyword in a constructor or at field declaration
• Static method calls in a constructor or at field declaration
• Anything more than field assignment in constructors
• Object not fully initialized after the constructor finishes (watch out for initialize methods)
• Control flow (conditional or looping logic) in a constructor
• Code does complex object graph construction inside a constructor rather than using a factory or builder
• Adding or using an initialization block

Warning Signs

• Objects are passed in but never used directly (only used to get access to other objects)
• Law of Demeter violation: method call chain walks an object graph with more than one dot (.)
• Suspicious names: context, environment, principal, container, or manager

Warning Signs

• Adding or using singletons
• Adding or using static fields or static methods
• Adding or using static initialization blocks
• Adding or using registries
• Adding or using service locators

Warning Signs

• Summing up what the class does includes the word “and”
• Class would be challenging for new team members to read and quickly “get it”
• Class has fields that are only used in some methods
• Class has static methods that only operate on parameters

Sleep Sort Algorithm

A sorting algorithm that is not very efficient in terms of time.

#!/bin/bash
function f(){
      sleep "$1"
      echo "$1"
}
while [ -n  "$1" ]
do
    f "$1" &
    shift
done
wait

It’s a sorting problem converted into a scheduling problem.

The OS scheduler will sort the n tasks to schedule them in the proper order, which takes O(nlogn) time.¹