How do we uphold these guarantees across multiple databases?

Ground Rules

• Each node can already enforce these properties locally.
• All nodes play by the rules (no malicious nodes).
• Messages either arrive in full or not at all.

Each node has to make local decisions
without global state.

Nodes might see operations in a different order.

Pros

Simple

Guaranteed to be Correct

Cons

The node needs to see all transactions.

Pros

Serving timestamps is fast.

No other bottlenecks.

Cons

When is a transaction committed?

Node 1 commits transaction

Node 2 commits transaction

Client: ???

Node 1 commits transaction

Node 2 aborts transaction

Node 1 committed the transaction.

Idea 3: Have the client report back

(This is called Two-Phase Commit)

Periodically re-send messages

Pre-commit is idempotent

Re-receiving a pre-commit doesn't
change the commit status.

Log commit status in case of repeat requests.

Ground Rules

• Each node can already enforce these properties locally.
• All nodes play by the rules (no malicious nodes).
• Messages either arrive in full or not at all.

If the node guarantees Durability,
it will come up in the same state.

Failure = Dropped Message

The node never comes back up.

When is the write durable?

Never!

How much durability do you need?

Idea: Replicate data to multiple nodes/sites/planets...

Pros

A backup node exists to come back up when a node blows up.

Cons

Have to wait two message round-trips (or more) to commit.

Idea: Do something like 2-Phase Commit

Some replicas have T1 then T2.
Some have T2 then T1.

Under 2PC, some nodes abort T1 and some abort T2.

Idea: Majority vote

$N$ Replicas

$> \frac{N}{2}$ votes needed for a commit.

We need to ensure that Bob sees at least one copy of Alice's write

Pidgeonhole Principle

Alice gets confirmation from $A$ nodes

Bob reads from $B$ nodes

If $A+B > N$ then Bob must read at least one of Alice's writes

What does a node assume when it fails to receive a message?

Assume Node Failure and fail over to replica

All data remains available....

... but if it was only a transient communication failure, there can be inconsistencies

Assume Connection Failure and wait longer

All data remains consistent....

... but unavailable while we wait