SkillVaultskills Browse all 500 skills

Interview · Version 1.4.0 · Reviewed 2026-08-02

System Design Coach

Practice and improve architecture review and interview practice with evidence, explicit trade-offs, and a verification plan.

4 method steps 6 documented failure modes 5 diagnostic checks 7 quality gates

Reviews architecture decisions, finds scaling risks, and asks focused interview follow-ups.

₹99 one-time

Get this skill archive

What this skill helps you do

  • Architecture review
  • Interview practice
  • Bottleneck discovery

How System Design Coach works

You provide

Requirements, scale numbers, and hard constraints

It inspects

Read/write ratio, hot keys, and the true latency budget

It decides

A design with named failure behavior per dependency

You verify

Arithmetic for peak load, storage growth, and fan-out

What it checks first

System Design Coach reviews architecture decisions, finds scaling risks, and asks focused interview follow-ups. Use it when the work involves Architecture review, Interview practice, Bottleneck discovery.

  1. The read-to-write ratio, which determines whether caching, replication, or partitioning is the primary lever.
  2. Whether the workload has a hot key or hot partition, since uniform-capacity reasoning fails immediately if it does.
  3. The consistency requirement per operation rather than per system — most systems need strong consistency in one place only.
  4. The actual latency budget and where it is spent, before any component is chosen.
  5. What happens during a partial failure of each dependency, which is where most designs are underspecified.

Failure modes it recognizes

  • A single ID-generation service becoming the write bottleneck and the single point of failure.
  • Cache stampede on expiry, where a popular key expires and every request recomputes it simultaneously.
  • Hot partition from a sequential or low-cardinality partition key, so scaling out adds no capacity.
  • Dual writes to a database and a search index without an outbox, producing permanent divergence on failure.
  • Synchronous fan-out to N services making availability the product of N availabilities.
  • Unbounded queue growth converting a throughput problem into an unbounded latency problem.

Answers it will reject

  • Choosing microservices before the domain boundaries are known, which converts a code problem into a distributed-systems problem.
  • Quoting throughput numbers without stating the unit of work, which makes capacity estimates meaningless.
  • Adding a cache to fix a write bottleneck, which addresses the wrong path entirely.
  • Designing for a scale three orders of magnitude beyond the requirement, paying complexity cost immediately for a hypothetical.

Decision rules it applies

  • Separate the read path from the write path before optimizing either; they have independent scaling characteristics.
  • Prefer idempotent operations plus at-least-once delivery over attempting exactly-once semantics.
  • If a component must be strongly consistent, isolate it and let everything around it be eventually consistent.
  • Estimate with arithmetic — requests per second, bytes per record, and fan-out — and state the assumptions.

Evidence it asks for

  • Compute peak QPS, storage growth per year, and bandwidth per request before selecting technology.
  • Identify the p99 path and the number of network hops on it.
  • Name the failure behavior of each dependency: fail open, fail closed, or degrade.

The method inside

  1. Turn architecture review into explicit functional requirements and quality-attribute constraints.
  2. Model the critical path, state, trust, and failure boundaries that govern interview practice.
  3. Compare viable designs for bottleneck discovery against weighted constraints and operational ownership.
  4. Select a design with consequences, rollout stages, observability, and a reversible adoption path.

Deliverables

  • Architecture review assessment
  • Interview practice decision and action plan
  • Bottleneck discovery verification checklist

Evidence requirements

  • Problem statement or interview prompt
  • Known constraints and assumptions
  • Candidate reasoning or draft solution

Quality gates

  • Every material claim traces to supplied evidence or is labeled as a hypothesis.
  • The response follows the declared deliverable contract.
  • No execution, access, measurement, or verification is invented.
  • Secrets and personal data are redacted rather than repeated.
  • The user receives a concrete independent verification step.
  • The relevant failure modes in this domain were considered rather than only the reported symptom.
  • No listed anti-pattern was recommended as a solution.

Example task

Input

Review my URL shortener design for 50 million redirects per day.

Expected output

Start by separating the write and redirect paths. Your first scaling risk is the single primary key-generation service...

Boundaries and compatibility

Ideal for

  • Architecture review: produce a decision or artifact grounded in supplied evidence.
  • Interview practice: produce a decision or artifact grounded in supplied evidence.
  • Bottleneck discovery: produce a decision or artifact grounded in supplied evidence.

Out of scope

  • Providing leaked interview questions
  • Pretending one answer guarantees a hiring level

Agent compatibility

  • GitHub Copilot custom agents
  • Claude Agent Skills / SKILL.md
  • Any instruction-following chat model

Tool policy: Advisory by default. No tools are assumed. If the host provides tools, use read-only evidence gathering unless the user explicitly approves a scoped write or execution action.