What's changed: Created Professional Cloud Database Engineer Chapter 1 (Domain 1 "Design": capacity and HA/DR = workload metrics/perf-cost/zonal-regional-multi-regional/maintenance windows/RTO-RPO-PITR; connectivity/access and DB choice = Cloud SQL Auth Proxy/private IP/CMEK/session poolers/audit, Cloud SQL/AlloyDB (vector/gen AI)/Spanner/Bigtable/Firestore, managed/SQL/NoSQL/vector).
1.1Capacity planning and HA/DR design
Understand database capacity/usage planning from current workload metrics and future requirements, performance/cost tradeoffs, multi-regional/regional/zonal deployment strategies, maintenance windows, and designing high availability and disaster recovery to meet RTO/RPO/PITR.
A Professional Cloud Database Engineer translates business/technical requirements into scalable, resilient, cost-effective databases. Design starts with capacity planning and availability/disaster recovery.
1.1.1Capacity planning and performance/cost
Capacity planning sizes database compute and storage from current workload metrics (CPU/memory/IOPS/connections) and future requirements. Evaluate the performance/cost tradeoff (machine type, storage type) to avoid over- or under-provisioning. Map "size from current + future" and "balance performance against cost."
1.1.2High availability and DR (RTO/RPO/PITR)
Availability comes from placement: zonal (single zone, weak) → regional (multi-zone, tolerates zone failure) → multi-regional (tolerates regional failure). Design DR by RTO (recovery time) and RPO (acceptable data loss), with PITR (point-in-time recovery) to roll back to a specific moment. Set maintenance windows to match availability requirements. Map "tolerate zone failure = regional (HA)" and "recover to a point in time = PITR."
Common: requirement → design. E.g., "DB tolerant to zone failure" = regional (HA); "tolerate regional failure" = multi-regional; "roll back to before a bad change" = PITR; "acceptable data loss/recovery time" = RPO/RTO; "size from current + future" = capacity planning from workload metrics; "fit downtime to availability" = maintenance windows.
Watch the mix-ups: (1) Do not confuse RTO (time), RPO (data loss), and PITR (point-in-time recovery). (2) Availability comes from placement spread (zonal is weak). (3) Size capacity for future requirements, not just current.
1.1.3Section summary
- Capacity planning = size compute/storage from current metrics + future; evaluate performance/cost
- Availability = zonal < regional (HA) < multi-regional
- Design DR by RTO/RPO with PITR; fit maintenance windows to availability
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. To make a database resilient to zone failure, which placement best fits?
Q2. To roll back a database to a specific point before a bad change/corruption, which feature?
Q3. Which correctly contrasts RTO and RPO?
Q4. What is the best approach to database capacity planning?
Q5. You need the highest availability tolerating a whole-region failure. Which placement?
Q6. To control planned downtime to match app availability requirements, what do you set?