Let’s assume we have two TrueTime-based timestamps, $T1$ and $T2$ , associated with two events on two nodes in the distributed system. If we know that our TrueTime uncertainty was always under the max (say 7 ms) and if $T1$ and $T2$ are apart by more than 7ms, then $T1$ would have happened before $T2$ if the value of $T1$ is less than the value of $T2$ . So under such conditions, TrueTime can provide the functionality of a vector clock.

Another way to enforce vector clock-like timing characteristics for a few events could be to wrap those events around synthetic read abstractions of Spanner. Doing so will consistently assign timestamps. Though such a solution will incur the cost of read transactions.

Though we should remember that real-world cause-and-effect chains might not be inferred with TrueTime timestamps. For example, if two timestamps of two unrelated events in two different systems have timestamps where one was smaller than the other, it does not mean that the first event caused the second event.

We encourage you to think further about how the availability of the TrueTime API with small uncertainty can help perform different functions in a distributed system.

Prologue

File Systems

Google File System (GFS)

Google Colossus File System

Facebook's Tectonic File System

Databases

Google Bigtable

Google Megastore

Google Spanner

Key-value Stores

Many-core Key-value Store

Scaling Memcache

SILT

Amazon DynamoDB

Concurrency Management

Two-phase Locking (2PL)

Google Chubby Locking Service

ZooKeeper

Big Data Processing: Batch to Stream Processing

MapReduce

Spark

Kafka

Consensus

Understanding Consensus: Two Generals, FLP, & Byzantine Generals

Two-phase Commit

State Machine Replication

Paxos

Raft

Epilogue

Quiz on Spanner

1 of 7