scalabilitylisted

# /scalability — Scalable Design Enforcement Every design, plan, and implementation MUST handle current load efficiently AND accommodate 10x growth without architectural changes. Design for the load you expect in 18 months, not the load you have today. **Why this matters:** Systems that aren't designed to scale hit walls — and those walls always appear at the worst time (launch day, viral moment, enterprise customer onboarding). Retrofitting scalability is 10-100x more expensive than building it in. **When to invoke:** During PLANNING (after `/gsd:discuss-phase`, before `/gsd:plan-phase`) and during REVIEW (as part of code review criteria). This skill applies to both new code and modifications to existing code. --- ## The Rules ### Rule 1: Stateless by Default Every service, function, and handler MUST be stateless unless there is an explicit, documented reason for state. - **No in-memory state** that would break with multiple instances. - **No local file system** for data that must survive restarts or be shared. - **Session state** goes in a shared store (Redis, database), never in process memory. - **Caches** must be external (Redis, Memcached) or have invalidation strategies for multi-instance. **Test:** Can you run 5 instances of this service behind a load balancer with no shared state? If no, fix it. ### Rule 2: Efficient Data Access Every database query and data access pattern MUST be designed for scale: | Pattern | Requirement | |---------|-------------| | Q