Spanner, TrueTime, and the CAP Theorem

CAP theorem

Spanner is a global, highly available SQL database that easily handles massive amounts of data and transaction volume due to its replication capabilities. All data inserted into the database is given a timestamp that is accurate in the present, and clients can perform global consistent reads without requiring locking.

According to the CAP theorem, only two of the following three features can coexist in a given system:

• C: Consistency

• A: Availability

• P: Tolerance to network partitions

Depending on which letter we omit, we get three distinct systems: CA, CP, and AP. For distributed systems, partitions are often unavoidable. Therefore, any distributed system has to give up either consistency (AP) or availability (CP), which is a tradeoff no one wants to undertake.

The CAP theorem was developed to make designers think about this trade-off. However, there are two crucial caveats:

1. We only need to forfeit something during an actual partition.

2. The actual theorem is about 100% availability.

Does Spanner violate the CAP theorem?

Spanner claims it is consistent and available even if it's a globally distributed system. Although it seems that Spanner has disregarded the CAP theorem, it is a CP system, because when partitions occur, Spanner opts for C and gives up A.

Standard RDBMS implementations are usually CA, but they cease to be CA systems in a distributed environment because of the network partition. For Spanner to claim to be a CA system, it should be in the following states of relative probabilities:

1. High availability of the system in real time so users are not impacted, or the impact is minimal

2. Low fraction of partition outages

Spanner does not guarantee 100% uptime. It gives five-nines of availability which means there are five minutes of downtime a year. Most relational databases require ten minutes or more a month for maintenance and so on. To upgrade the schema, the databases require downtime too. Therefore, this is how Spanner backs up its "essentially CA" claim by providing high availability so users can tolerate outages.

The following illustration shows the outages of the Spanner due to unexpected events (the data is taken from hereBrewer, Eric. "Spanner, TrueTime and the CAP theorem." (2017)). Most events are caused by the Users themselves, whether through overload or incorrect configuration, but the other categories may affect several users. Events in a cluster indicate a larger issue with the underlying infrastructure, such as servers or power. Spanner will automatically switch to a different replica to avoid downtime. Misconfigurations and Site Reliability ...