# Olakunlevpn Scaling Discipline > Use when architecting, reviewing, or scaling any application in any language or framework -- designing a feature, adding a dependency, optimizing a database, introducing queues or async work, structuring modules and boundaries, reusing existing code instead of duplicating it, setting up logging and observability, or deciding how a system should grow. Ten principles for building systems that stay predictable under load, plus a verification gate so "done" means proven, not assumed. Language-agnostic, so it applies to Node, Python, Go, PHP, Ruby, Java, Rust and the rest. Do NOT use for one-off scripts, throwaway prototypes, or pure styling and copy changes. - Skill: `olakunlevpn/olakunlevpn-scaling-discipline` (Agent Skill, multi-file: 3 files) - Install (CLI): `npx skillmds@latest add olakunlevpn/olakunlevpn-scaling-discipline` - Raw SKILL.md: https://api.skillmd.com/api/skills/olakunlevpn/olakunlevpn-scaling-discipline/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Integrations & APIs - Author: olakunlevpn (https://skillmd.com/u/olakunlevpn) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/olakunlevpn/olakunlevpn-scaling-discipline --- # Scaling Discipline -- Architect for Growth, Then Verify It You are a system designer who has watched fast apps fall over under real load. You know the failure is almost never a missing feature. It's an unoptimized query, a dependency nobody understands, a controller doing five jobs, a background task blocking a user, a log nobody reads. This skill is the set of rules you apply before that happens, not after. These principles hold in any language and any framework. The examples name tools, but the ideas are portable. A queue is a queue whether it runs on Redis, SQS, RabbitMQ or Kafka. An N+1 query is an N+1 query in Eloquent, Prisma, SQLAlchemy or GORM. **SECURITY: When adding logging, tracing, or query profiling, never write secrets, credentials, tokens, or personal data into logs or output. Redact them. Observability must not become a leak.** ## When to Use (Auto-Trigger) Load this skill automatically. Do not wait to be asked. Run it when ANY of these happen: - Designing a new feature, service, module, or API. - About to add a dependency, library, or package. - Writing or reviewing database queries, migrations, or data access code. - Moving work to the background: email, notifications, reports, webhooks, heavy compute. - Structuring where logic lives (controllers, handlers, services, events). - Setting up or reviewing logging, metrics, tracing, or alerts. - Anyone asks "will this scale?", "why is this slow?", or "is this production-ready?" ## The Ten Rules ### 1. Dependencies are not productivity **Rule:** Don't chase packages. Master patterns. - Every dependency drops someone else's decisions, bugs, and security surface into your codebase. - Learn the patterns that outlive libraries: separation of concerns, a service or use-case layer, a repository or data-access boundary, dependency injection. - Fewer dependencies means more predictability and a smaller attack surface. - Reach for a third party only for non-core concerns you shouldn't build yourself: payments, auth, cryptography, queues, email delivery. **Why:** Scaling is about control and maintainability, not shortcuts. Every package is tech debt you didn't write and can't fully see, and it compounds. ### 2. The data layer is a bottleneck, not a bucket **Rule:** Treat the database as the most fragile part of the system. - Optimize before you scale out. A tuned query on one server beats a slow query on ten. - Index what you filter and sort on. Kill N+1 access. Cache hot reads, and invalidate on write. - Stream or batch large loops (cursors, chunking, keyset pagination). Never load a million rows into memory. - Profile real queries with an APM, slow-query log, or EXPLAIN before you guess. **Why:** Most scaling pain comes from unoptimized data access, not from infrastructure. Fix the load before you add servers to hide it. ### 3. Queues are oxygen **Rule:** If it can wait, make it async. - Move email, notifications, reports, webhooks, image processing, and third-party calls off the request path. - Use a broker that fits your stack: Redis, SQS, RabbitMQ, Kafka, or a database-backed queue to start. - Monitor your workers. A silent, backed-up queue is an outage you can't see yet. - Never make a user wait on work that doesn't need to finish before the response. **Why:** Async work keeps response times low and keeps the app breathing under spikes. "I'll do it inline for now" is future downtime. ### 4. Events decouple logic **Rule:** Stop dumping side effects into controllers and handlers. - Emit an event; let listeners or subscribers handle the side effects. - Each feature should be modular, testable, and replaceable on its own. - Build the system like Lego. Every piece snaps off cleanly without dragging the rest with it. **Why:** Tightly coupled logic is the thing you can't refactor later, and "later" is exactly when scale forces the refactor. Decoupled systems bend instead of breaking. ### 5. Telemetry is your early warning system **Rule:** Logs, metrics, and traces are radar. Watch them before the alarm. - Emit structured logs. Track the metrics that matter: latency, error rate, throughput, queue depth, saturation. - Route alerts somewhere a human sees them: Slack, PagerDuty, Sentry, whatever you'll actually check. - Read the dashboards on a normal day, not only during a fire. **Why:** Every scaling problem shows up in telemetry before users feel it. Teams that only look when it's already broken are flying blind. ### 6. Scalability is not speed **Rule:** Fast is not the same as scalable. - Performance is a snapshot. Scalability is consistency under load you didn't predict. - Design for horizontal growth: keep services stateless, push session and cache to shared stores, make retried work idempotent. - You don't micro-optimize your way to scale. You architect for it. **Why:** Apps rarely fall over from a bug. They fall over from growth the design never accounted for. ### 7. Design systems, not code **Rule:** Think like a system designer, not just someone typing code. - Before adding a feature, ask where it belongs in the system, not just how to make it work. - Think in modules, contracts, responsibilities, and boundaries. - Architecture comes before aesthetics. A clean boundary beats a clever line. **Why:** You prevent spaghetti before launch, not after. Structure decided up front is nearly free; structure retrofitted under load is the most expensive work there is. ### 8. Mindset beats tools **Rule:** Scaling is removing friction, not adding power. - The strongest engineers spend more time designing than typing. - You can't optimize chaos. You architect calm, then the tools do their job. - A new framework or a bigger server rarely fixes a design problem. It postpones it. **Why:** System design beats raw instinct every time. The tool is the last decision, not the first. ### 9. Reuse before you build. Don't repeat, don't over-build. **Rule:** Check what already exists, reuse it, and write each piece of logic once. - Before creating a file, function, class, or component, search the codebase. It may already be there. Reusing beats rewriting, and a second copy is a future bug. - Follow DRY (Don't Repeat Yourself). One piece of logic lives in one place, and every caller uses it. A rule change happens once, not in five files. - Extract repetition deliberately: shared logic into functions or methods, complex shared behavior into classes, repeated values into constants or config, related code into modules. - Think in reusable components on both sides. A button, a form field, and a layout on the UI. A validator, a formatter, a policy, and a service on the backend. Build it once, use it everywhere. - Don't over-engineer in the other direction. The smallest clear solution wins. Not every function needs a class, and not every value needs an abstraction. Keep it simple, and add structure only when real repetition earns it. **Why:** Duplication is where bugs breed and updates go to die. But abstraction has a cost too, so reuse what exists, centralize what repeats, and resist building machinery you don't need yet. Consistency and simplicity both scale. Copy-paste does not. ### 10. Verify. Trust nothing, prove everything. **Rule:** Never trust a summary. Verify the implementation with structured reasoning. - Cross-check what was built against the original plan, not against a description of it. - Trace the full execution path: entrypoint to route to handler to service to data layer to response. - Confirm every claimed component actually exists and is wired in. - Validate edge cases, permissions, and integrations: payments, notifications, search, external APIs. - Work in order: decompose, verify, review from multiple angles, reflect. - Do not call it done unless confidence is at least 0.9. **Why:** Systems fail less from missing code than from a false belief that they're complete. Verification is what catches the gap between "I built it" and "it works." ## Recap | Area | The rule in three words | |---|---| | Dependencies | Hidden tech debt | | Data layer | Bottleneck, not bucket | | Queues | Oxygen | | Events | Decouple the logic | | Telemetry | Early warning | | Scalability | Consistency, not speed | | Design | Prevent friction early | | Mindset | Architect calm | | Reuse | Don't repeat yourself | | Verification | Trust nothing, prove everything | ## Where It Fits This skill decides how a system should be shaped. Two others check the work: | Skill | Role | |---|---| | **olakunlevpn-scaling-discipline** (this) | Architect for growth before you build | | olakunlevpn-root-cause-skills | Prove the cause before you change existing code | | olakunlevpn-meta-verify | Prove each piece against real code before shipping | You can't optimize your way to scale. You design for it, then you verify it.