Capacity vs Efficiency: Building a Globally Scalable Cloud Database
summary
Google Cloud Firestore runs as a fully scalable pay-per-request NoSQL database and the operational claim is that efficiency comes from shrinking paid idle capacity while still surviving sudden spikes. Key tactics: convert sync to async to remove thread bottlenecks, align autoscaler signals, use dual-window autoscaling and short startup VMs, publish the 555 rule (start 500 RPM, every 5 minutes +50), spread across many zones to reduce N+1 overhead (2 zones makes +1 a 50% waste, 5 zones makes it 20%), run batch work on spot instances, apply load shedding and QRS with a stride scheduler for per-customer CPU isolation, and budget headroom against P95/P99 targets.
AI-written summary · about
chapters (22)
- 0:00Intro
- 2:14Case Study: Google Cloud Firestore
- 4:08Autoscale Everything
- 5:30Autoscaling Signals
- 6:50Traffic Patterns
- 9:41Choosing Your Headroom
- 11:31Stockout Resilience
- 13:16Provisioning For Failover
- 15:32Tuning The Autoscaling
- 19:41Load Balancing
- 21:18Probability Distributions
- 22:14Efficient Failovers
- 24:43Batch Traffic
- 25:52Finding The Right Shape
- 26:53Bigger Is Better
- 29:22Resource Tradeoffs
- 30:56Overload And Efficiency
- 32:12Understand Your Limits
- 33:49Loadshedding
- 35:45Quality Of Service
- 36:45Fairness Under Overload
- 38:06The Efficiency Formula
related talks
37mBuilding Scalable Apps with Cloud Firestore
41mUsing Cloud Firestore to Build Planetary Scale Apps
30mBuilding distributed systems is hard - case study (...)
37mGoogle Cloud Spanner: Going global with relational database
27mScalable by Design: How to Build an Elastic Cloud Infrastructure...
33mCloud Storage Choosing the Best
11mDatabase Evolution: Partitioning and Indexing
41mCloud Firestore Data Modeling