Scale Game
Test approaches at extreme scales to find what breaks and what survives.
[GOAL]
Validate an approach by testing it at extreme scales to expose hidden assumptions and limits.
[CONTEXT]
Core principle: Extremes expose fundamental truths hidden at normal scales.
Use when:
- •Uncertain about scalability
- •Edge cases unclear
- •Validating architecture for production volumes
- •"It works in dev" needs verification
[PROCESS]
- •Pick dimension - What could vary extremely?
- •Test minimum - What if 1000x smaller/faster/fewer?
- •Test maximum - What if 1000x bigger/slower/more?
- •Note what breaks - Where do limits appear?
- •Note what survives - What's fundamentally sound?
[SCALE DIMENSIONS]
| Dimension | Test At Extremes | Reveals |
|---|---|---|
| Volume | 1 item vs 1B items | Algorithmic complexity limits |
| Speed | Instant vs 1 year | Async requirements, caching needs |
| Users | 1 user vs 1B users | Concurrency issues, resource limits |
| Duration | Milliseconds vs years | Memory leaks, state growth |
| Failure rate | Never fails vs always fails | Error handling adequacy |
[EXAMPLES]
Error Handling
- •Normal: "Handle errors when they occur" works fine
- •At 1B scale: Error volume overwhelms logging, crashes system
- •Reveals: Need to make errors impossible or expect them
Synchronous APIs
- •Normal: Direct function calls work
- •At global scale: Network latency makes sync calls unusable
- •Reveals: Async/messaging becomes survival requirement
In-Memory State
- •Normal duration: Works for hours/days
- •At years: Memory grows unbounded, eventual crash
- •Reveals: Need persistence or periodic cleanup
[IMPORTANT]
- •Test both directions (bigger AND smaller)
- •What works at one scale fails at another
- •Use insights to validate architecture early
- •Don't assume "should scale fine" without testing
See Also
- •[[when-stuck]] - Dispatch to right technique
- •[[simplification-cascades]] - Find unifying abstractions