Production gotchas — premature scaling and the missing capacity plan

At a glance

Learning objectives

• Recognize premature scaling as a design smell with a pager attached
• Treat capacity planning as standing SRE work with its own cadence
• Spot retry storms and assumption rot before they become incidents

What you need

• Lessons 5–7 (budgets, patterns, precedents — gotchas attack all three)
• One system whose growth assumptions you cannot currently state

Steps

1. Name the missing discipline — capacity planning is in the SRE books' scope right beside SLIs/SLOs/error budgets and incident management, so a platform without a capacity plan is missing canonical SRE work, not a nice-to-have. (from ref-sre-google )
2. Question scale assumptions early — DDIA's scalability chapters exist because load assumptions age badly, and the book's payoff is understanding why tools are shaped as they are, which includes why they stop being enough. (from ref-ddia )
3. Drill the failure before it happens — the SRE material covers postmortem culture and incident management that data platform teams already borrow for incident drills, so rehearse the capacity surprise while it is still hypothetical. (from ref-sre-google )
4. Audit the failure policies you shipped — the pattern catalogue's considerations for retry and circuit breaker exist precisely because misapplied resilience multiplies load, and a retry storm is premature scaling wearing a good intention. (from ref-cloud-design-patterns )
5. Diff against deployed guidance — AWS's best-practice guidance (Well-Architected pillars) is the cheapest external review available; when your architecture drifts from the pillars, assume the drift is the bug until proven otherwise. (from ref-aws-arch-center )

Check yourself

• For every component in your platform you can state its current utilization and the load at which it breaks — or you know it is unmeasured.
• The last three components you added each paid for themselves in reduced toil or risk, and you can name which.

Worked example

Premature scaling    -> complexity bought before load requires it;
                        every extra moving part is a pager
No capacity planning -> the SRE books treat capacity planning as core
                        work, not an afterthought; without it the first
                        growth spike is the experiment
Retry storm          -> retries without budget/breaker multiply load
                        exactly when the system is weakest
Assumption rot       -> scale assumptions from launch day, never revisited

Sourced from

• Google SRE Books
• Designing Data-Intensive Applications (O'Reilly)
• Azure Cloud Design Patterns
• AWS Architecture Center

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• Premature scaling is a complexity debt — every extra moving part is a pager that did not exist last year.
• No capacity plan means the first growth spike is the experiment — run the drill before load runs it for you.
• Retries without a budget or breaker multiply load exactly when the system is weakest — that is a storm.

Production considerations

• Re-derive capacity numbers quarterly from utilization data, not from the original design doc.
• Add breaker trip counts and retry volumes to the ops review — they are scaling symptoms in disguise.

Diagram

production gotchas
   |
   |- premature scaling --> complexity bought before load requires it
   |                      -> every moving part is a future pager
   |
   |- no capacity plan  --> first spike is the experiment
   |                      -> capacity planning is standing SRE work
   |
   |- retry storm       -> resilience misapplied multiplies load
   |- assumption rot    -> launch-day scale numbers never revisited
   |
    --> diff the architecture against the pillars; drift is a bug

Registry stats