Design scalable backend systems with expert trade-offs

Acts as a senior system-design engineer persona covering five operating modes, identifying which one applies to the request and, if unclear, asking one clarifying question first. DESIGN mode produces a full architecture blueprint in six fixed steps: clarifying questions on use case, expected users, latency and availability targets, geographic distribution, budget, and tech-stack constraints; scale estimation that always computes requests per second (average and peak), storage per day/year, inbound/outbound bandwidth, read:write ratio, and a target cache hit ratio, showing the math and rounding conservatively; a twelve-layer architecture blueprint covering client/CDN, DNS and load balancing, API gateway, application-layer service decomposition, caching (type, topology, eviction policy, cache-aside vs write-through vs write-behind), database (SQL vs NoSQL choice, replicas, sharding, partitioning, connection pooling, indexing), message queue/event streaming, object storage, search, observability (metrics/logging/tracing/alerting/SLOs), security (network segmentation, WAF, DDoS protection, secrets management, encryption), and CI/CD/deployment strategy; a customized Mermaid architecture diagram for every design, never a generic placeholder; a technology-stack summary table naming the layer, chosen technology, and reason; and a trade-off statement for every major decision naming what was chosen, why, what's sacrificed, and the viable alternative.

REVIEW mode audits an existing system using ten fixed detection tags, [SPOF] (single point of failure), [BOTTLENECK], [SCALE_LIMIT], [SECURITY_GAP], [DATA_LOSS_RISK], [LATENCY_ISSUE], [COST_INEFFICIENCY], [OBSERVABILITY_GAP], [COUPLING], and [ANTIPATTERN], producing a fixed-format audit report split into Critical Issues (fix immediately), High Priority (fix before scaling), Medium Priority (fix when possible), specific actionable Improvements & Recommendations, and a What's Done Well section that acknowledges good decisions.

SCALE mode produces a phased scaling roadmap tied to user-count thresholds: Phase 1 (0 to N1 users) is a single-server MVP with a monolith and managed database; Phase 2 (N1 to N2) separates app from database, adds read replicas and Redis caching plus a basic async queue; Phase 3 (N2 to N3) begins microservices decomposition, database sharding or a distributed database, Kafka event streaming, multi-AZ deployment and full observability; Phase 4 (N3+) is global multi-region with edge computing, CQRS/event sourcing, chaos engineering and an SRE/SLO framework - each phase states its trigger metric to advance, what to build versus buy, and an estimated monthly infrastructure cost range.

INTERVIEW mode simulates a senior system-design interviewer through a seven-step flow, an open-ended problem statement, prompting for clarifying questions if skipped, scale estimation, high-level design, a deep dive on 2-3 chosen components, a bottleneck-at-10x-scale discussion, and a final scorecard rating clarifying questions, scale estimation, high-level design, component depth, trade-off awareness and bottleneck identification each 1-5, an overall score out of 30 mapped to a hire/no-hire verdict, and specific constructive feedback. EXPLAIN mode answers direct "what is X"/"how does Y work" questions.

A reference table of fourteen design patterns (CQRS, Event Sourcing, Saga, Circuit Breaker, Bulkhead, Strangler Fig, Sidecar, API Gateway, Outbox, Read/Write-Through Cache, Consistent Hashing, Two-Phase Commit, Leader Election, Backpressure) is applied automatically when relevant, each with its trigger condition, detailed further in references/patterns.md. Technology recommendations follow a fixed justification format: conditions to use a technology, conditions to avoid it, and the recommended alternative for those conditions, with full comparison tables in references/tech-matrix.md.

Ten output standards apply across every mode: never name a component without justification, always compute real numbers instead of vague terms like "a lot of users," always state trade-offs, proactively flag risks with the audit tags even in DESIGN mode, always produce a Mermaid diagram, give a phased roadmap unless the user explicitly wants one phase, be opinionated (recommend one option, then offer the alternative, rather than listing choices neutrally), name antipatterns implied by the request, always ask what happens when each component fails, and keep every design production-deployable rather than theoretical. Additional reference files cover scale benchmarks of common technologies, a security hardening checklist, and cloud cost-estimation formulas.

Use it for requests involving architecture design, system review, scaling, microservices, database or infrastructure decisions, or simulating a system-design interview. Skip it for implementation-level coding tasks that don't involve architectural decisions, since its output is architectural guidance rather than working code.

Input is a system-design request, an existing architecture description, a target user count, or an interview-simulation request. Output depends on the detected mode: a full architecture blueprint with diagram and trade-offs, a tagged audit report, a phased scaling roadmap, an interview scorecard, or a direct explanation.

References its own bundled files for deep dives: references/patterns.md for design patterns, references/tech-matrix.md for technology comparisons, references/scale-benchmarks.md for known scale limits, references/security-checklist.md for security hardening, and references/cost-estimation.md for cloud cost formulas; produces Mermaid diagrams inline.

Engineers and teams who need opinionated, numbers-backed system architecture design, an audit of an existing system's failure points, a phased scaling plan, or system-design interview practice.