home / skills / yousufjoyian / claude-skills / scale-game

scale-game skill

/problem-solving/scale-game

This skill helps you explore systems under extreme scales to reveal fundamental truths and guide architectural decisions.

This is most likely a fork of the scale-game skill from mamba-mental
npx playbooks add skill yousufjoyian/claude-skills --skill scale-game

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.2 KB
---
name: scale-game
description: Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales
---

# Scale Game

## Overview

Test your approach at extreme scales to find what breaks and what surprisingly survives.

**Core principle:** Extremes expose fundamental truths hidden at normal scales.

## Quick Reference

| Scale Dimension | Test At Extremes | What It 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 |

## Process

1. **Pick dimension** - What could vary extremely?
2. **Test minimum** - What if this was 1000x smaller/faster/fewer?
3. **Test maximum** - What if this was 1000x bigger/slower/more?
4. **Note what breaks** - Where do limits appear?
5. **Note what survives** - What's fundamentally sound?

## Examples

### Example 1: Error Handling
**Normal scale:** "Handle errors when they occur" works fine
**At 1B scale:** Error volume overwhelms logging, crashes system
**Reveals:** Need to make errors impossible (type systems) or expect them (chaos engineering)

### Example 2: Synchronous APIs
**Normal scale:** Direct function calls work
**At global scale:** Network latency makes synchronous calls unusable
**Reveals:** Async/messaging becomes survival requirement, not optimization

### Example 3: In-Memory State
**Normal duration:** Works for hours/days
**At years:** Memory grows unbounded, eventual crash
**Reveals:** Need persistence or periodic cleanup, can't rely on memory

## Red Flags You Need This

- "It works in dev" (but will it work in production?)
- No idea where limits are
- "Should scale fine" (without testing)
- Surprised by production behavior

## Remember

- Extremes reveal fundamentals
- What works at one scale fails at another
- Test both directions (bigger AND smaller)
- Use insights to validate architecture early

Overview

This skill teaches a simple, practical method: push designs to extreme scales to expose hidden assumptions and failure modes. By testing 1,000x smaller and 1,000x larger (and instant vs year-long), you discover which parts of a system are brittle or robust. The goal is to reveal fundamental truths early so you can change architecture or operations before production pain.

How this skill works

Pick a dimension that matters (volume, speed, users, duration, failure rate). Run thought experiments, focused tests, or load experiments at extreme low and high values and observe what breaks and what survives. Record the limits you hit, the implicit assumptions that fail, and the design patterns that remain valid. Use those findings to drive concrete architecture, monitoring, and testing changes.

When to use it

  • Design reviews before major implementation or launch
  • Performance and reliability planning for new features
  • Post-mortems to probe why incidents escalated
  • Architecture trade-offs where long-term costs are unclear
  • When teams assume "it will scale" without evidence

Best practices

  • Choose one scale dimension per experiment to keep tests focused
  • Combine thought experiments with small, targeted prototypes or simulations
  • Log failures and resource use differently at extremes to see hidden bottlenecks
  • Test both directions: much smaller/faster and much larger/slower
  • Translate insights into concrete mitigations (backpressure, persistence, async)

Example use cases

  • Verify whether synchronous APIs become bottlenecks when global latency increases
  • Check if in-memory caches can survive multiyear retention or require eviction
  • Simulate 1B users to uncover concurrency and resource limits before launch
  • Force high error rates to validate error handling, alerting, and fallback logic
  • Run ultra-fast or ultra-slow event streams to determine async and retry needs

FAQ

How do I pick which dimension to test first?

Start with the dimension most tied to business risk: user volume for consumer products, duration for long-running state, speed for real-time systems.

Do I need full-scale infrastructure to run these tests?

No. Use targeted simulations, sampling, and thought experiments. Emulate bottlenecks, scale resource usage proportionally, or run focused load tests on critical components.