home / skills / mamba-mental / agent-skill-manager / scale-game

scale-game skill

safe

This skill helps you explore system design under extreme scales to reveal bottlenecks and validate architecture with practical insights.

npx playbooks add skill mamba-mental/agent-skill-manager --skill scale-game

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

Files (1)

SKILL.md

2.3 KB

---
name: Scale Game
description: Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales
when_to_use: when uncertain about scalability, edge cases unclear, or validating architecture for production volumes
version: 1.1.0
---

# 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 helps you stress-test designs by pushing every dimension to extreme values to reveal hidden assumptions and failure modes. It encourages rapid experiments at 1000x smaller and 1000x larger, and across time and reliability extremes, to surface what truly matters. Use it early to validate architecture, APIs, and operational plans before they reach production.

How this skill works

Pick a scale dimension (volume, speed, users, duration, failure rate) and run two focused experiments: one at an extreme minimum and one at an extreme maximum. Observe where systems break and what survives, then iterate on design choices like async patterns, persistence, and error strategies. The technique converts anecdotal confidence into concrete limits and actionable fixes.

When to use it

When something "works in dev" but you lack production confidence
During architecture reviews or before major launches
When requirements mention "should scale" without evidence
To stress-test error handling, state management, or latency assumptions
When planning for long-lived state or multitenant growth

Best practices

Define clear metrics and success criteria for each extreme test
Test both directions—drastically smaller and drastically larger—to expose different weak points
Automate reproducible experiments so you can rerun after fixes
Isolate variables: change one dimension at a time to pinpoint root causes
Treat findings as requirements: convert survivals into guarantees and failures into mitigations

Example use cases

Validate error handling by simulating billions of failures to check logging, aggregation, and incident volume strategies
Evaluate API design by comparing synchronous calls at global latency vs async messaging at scale
Discover state-management limits by running a feature for milliseconds vs years to reveal memory growth and persistence needs
Assess capacity planning by simulating 1 user vs 1 billion users to uncover concurrency and resource bottlenecks
Refine testing strategy: force extreme reliability and constant failure to ensure graceful degradation and retry logic

FAQ

How extreme should the tests be?

Pick large multipliers like 1000x or simulate instantaneous vs year-long behavior; the exact numbers are less important than forcing qualitatively different regimes.

Can I do this without real traffic?

Yes—use simulations, load generators, fault injection, and time-travel testing to mimic extremes before real traffic exists.