- Facebook's goal is to making features and selling ads
- Only scaling if they need to
- Multiple Front End Servers
- Still a Single backend database
- Don't have to worry about things like distributed transactions
- Multiple Front End Servers, Multiple Databases Shared
- a-g for database 1, g-q for database 2, q-z for database 3
- MEMCACHE Servers
get(key, value)
put(value)
- a cache for data that is hit often "hot" data
- but if a MEMCACHE fails, the database will fail
- the database usually only sees a few percent that the caching layers sees!!!
- Stale data doesn't really matter
- just some pictures from friends from last hour, etc.
- Two datacenters
- Try to avoid cross nation communication
- delete for overwriting, because the data in the cache is stale
- performance by:
- partition
- RAM efficient
- not efficient for hot keys
- replication
- good for hot keys
- few TCP connections
- replication between datacenters
- sharded database
- multiple clusters
- FE to MC connections is \( O(N^2) \) so have to limit it and make it in clusters
- Regional Pool Cache
- a problem where a miss causes other front end servers to overload the database
- instead use a lease
- a number
- invalidate the lease
- when trying to write note lease is invalid, write is invalid
- when deleting, use gutter memcache
- we get into a data race
- problem - data is out of date forever!
- use lease again