eddowding/scale-game

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