Web scale for the rest of us
summary
Argues that practical scaling means concrete tradeoffs: pick Postgres or MySQL not MongoDB, run unicorn + nginx, start with two app servers plus a util server and a DB master/slave, and expect the 1→2 developer and 1→2 server jumps to be the hardest. Advocates YAGNI for premature ops work, use caching selectively, handle failover with cap tasks (one experienced failover takes about five minutes), and prefer Rackspace or Heroku depending on cost versus operational simplicity.
AI-written summary · about
chapters (11)
- 0:00Introduction
- 3:55Defining scaling for startups
- 7:48Rails and DevOps
- 11:03Single server principle
- 14:57YAGNI in operations
- 17:49Minimal viable stack
- 21:24SQL for Rails
- 25:44High availability rules
- 31:24Etsy’s operations
- 33:12Good Films case study
- 40:44Q&A
related talks
29mWhen Web Scale Doesn't Make Sense
41mForget Scaling: Focus on Performance
05mScale Fail
33mKeynote: Rails Doesn't Scale
28mSmall Data: Databases in the real world
44mSchrodinger's Elephant
28mSimplifying at Scale: 7 Years of Rails Architecture
44mRunning Non-Cloud-Native Databases in Cloud-Native Environments