Atomicity

A transaction is either applied fully (COMMITed) or not at all (ABORTed).

Consistency

Constraints are enforced on the final state of the transaction (and the transaction is ABORTed if they fail).

Isolation

Two transactions running in parallel don't interfere with each other

Durability

Once the database returns from a COMMIT successfully, the data is safe from marmots

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.

Idea 1: Route all requests through one node

Pros

Simple

Guaranteed to be Correct

Cons

The node needs to see all transactions.

Idea 2: Have one node define a serial order

Force each node's interactions to obey the order.

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)

Failure Analysis

What kinds of failures can we tolerate?

• A message is dropped
• A node crashes
• Radioactive marmot attack

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.

Failure Analysis

What kinds of failures can we tolerate?

• A message is dropped
• A node crashes
• Radioactive marmot attack

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

Failure Analysis

What kinds of failures can we tolerate?

• A message is dropped
• A node crashes
• Radioactive marmot attack

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.

When can we consider a replica write successful?

What is a success?

A "successful" read reads the written value.

Can we do better than 2PC?

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

Timeouts

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