Senior · Docker and Kubernetes
Autoscaling without melting storage
Why can adding Go replicas make the system slower?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
More replicas increase aggregate database pools, background jobs, cache warmups and retry traffic. If storage is the bottleneck, extra clients add contention rather than useful throughput.
Choose scaling signals that reflect the workload: CPU can work for CPU-bound APIs, while queue age or demand may be better for workers. Bound per-replica and global resource demand and avoid a single-tenant burst monopolizing capacity.
Model cold start, cache misses and graceful scale-down. Observe offered load, saturation and completions; scaling must respect downstream capacity and the business latency target.
Common trap
HPA is a control loop, not unlimited capacity or a substitute for admission control.
Try it
HPA doubles replicas during a cache outage while MongoDB is already saturated. What policy helps?
Worked solution
Cap database concurrency across replicas, collapse/limit cache fills and shed or defer overload. Scale only when the additional capacity addresses the bottleneck. Use queue-age and dependency saturation to interpret CPU, not blindly react to one metric.
Change the constraint
How would you avoid synchronized cache warmup after a fleet-wide rollout?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.