---
id: gh-scale-game
name: "Scale Game"
url: https://skills.yangsir.net/skill/gh-scale-game
author: obra
domain: ai-system-observability-sre
tags: ["scalability", "system-design", "performance-testing", "reliability", "architecture-validation"]
install_count: 520
rating: 4.20 (120 reviews)
github: https://github.com/obra/superpowers-skills/tree/main/skills/problem-solving/scale-game
---

# Scale Game

> 此技能通过在极端规模（如1000倍大/小、瞬间/一年）下测试系统，揭示在正常规模下隐藏的根本性问题和真相。它帮助用户识别系统限制、潜在故障点和架构弱点，从而构建更健壮、可扩展且可靠的软件。

**Stats**: 520 installs · 4.2/5 (120 reviews)

## Before / After 对比

### 生产系统稳定性

**Before**:

在没有这个技能之前，用户常常在生产环境中遭遇意想不到的性能瓶颈和系统崩溃，导致长时间的故障排查和业务中断。团队对系统在极端负载下的行为缺乏预知，难以有效规划资源和优化架构。

**After**:

此技能通过模拟极端场景，帮助用户在部署前发现并解决潜在的扩展性问题，显著减少生产事故的发生。该 Skill 使得团队能够更自信地应对高并发和大数据量挑战，确保系统稳定运行。

| Metric | Before | After | Change |
|---|---|---|---|
| 生产事故解决时间 | 120分钟 | 15分钟 | -87% |

## Readme

# 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


---
*Source: https://skills.yangsir.net/skill/gh-scale-game*
*Markdown mirror: https://skills.yangsir.net/api/skill/gh-scale-game/markdown*