Transactions across datacenters - Google IO 2009

gistfile1.txt

## Consistency?
### Weak
- After a write, reads may or may not see it
- Best effort only
- Memcached
- VoIP, live online video
- Online multiplayer games

### Eventual
- After a write, reads will eventually see it
- Mail
- Search engine indexing
- DNS, SMTP
- Amazon S3, SimpleDB

### Strong
- After a write, reads will see it
- File systems
- RDBMSes
- Azure tables

## Why transactions?
Transfer money from A to B:
1. Subtract from A
2. Add to B

What if something else happens between those operations?

- Correctness
- Consistency
- Enforce invariants
- ACID

A (atomic): 
C (consistent): 
I (isolated): 
D (durable): 

## Why across datacenters?
- Catastrophic failures: fires, power shortage
- Geolocality: server close to the user => less latency
- CDN

Within a datacenter
- High bandwidth: 1 - 100Gbps
- Low latency: < 1 ms within rack, 1 - 5 ms across
- Cheap

Between datacenters
- Low bandwidth: 10 Mbps - 1 Gbps
- High latency: 50 - 150 ms
- Fiber is expensive!


## Multihoming
- Hard problem
- ... consistenly? -> harder
- ... with real time writes? -> hardest

Option 1: don't
- Bunkerize: MS Azure, Amazon SimpleDB
- Bad at catastrophic failure: data loss
- Not great for serving: no geolocation

Option 2: primary with hot failover(s)
- Better but not ideal: mediocre at catastrophic failure, window of lost data, failover data may be inconsistent
- Amazon Web Services: EC2, S3, SQS, choose US or EU; EC2 - availability zones, ELB
- Banks, brokerages
- Geolocated for reads, not for writes

Option 3: true multihoming
- Simultaneous writes in different DCs
- Two way: hard
- N way: harder
- Handle catastrophic failure, geolocality
- ... but pay for it in latency

## Techniques and tradeoffs
## Conclusions
- No silver bullet!