System design

QPS average  = daily actions / 86,400 s
QPS peak     ≈ QPS average × peak factor (2-10, often 3)
Storage/year = writes/day × bytes per write × 365
               × replication factor (plus index overhead)
Bandwidth    = QPS × bytes per response   (× 8 for bits/s)
Servers = peak QPS / (QPS per server × target utilization)
Concurrency  = arrival rate × latency      (Little's law)
 
1 million requests/day ≈ 12 per second
1 billion requests/day ≈ 12,000 per second

<context>
I want to build [system, e.g. a photo-sharing
app: upload, follow, home feed, likes]. It's for
[purpose: design doc | design review | interview practice].
What exists: [current state, e.g. nothing yet;
an AWS account, 4 engineers who know Postgres].
I have never designed a system that runs on many machines.
</context>
 
<task>
Interview me before designing anything. The end result
will be a design document (requirements, estimates,
API, data model, architecture, failure-mode analysis);
first you need the requirements and the numbers.
</task>
 
<requirements>
- At most 10 questions, grouped under: scope and
  use cases; users and load; latency, availability
  and durability targets; consistency per
  operation; data size and retention; geography and
  residency; stack, team and operations; budget.
- For each question: one line on how the
  answer changes the design, and 2–3 typical
  answers, with numbers, I can pick from.
- No architecture, technologies or estimates yet.
</requirements>
 
<quality_bar>
Before answering, check your questions against:
- Each answer would change a number or a
  component; drop any question that wouldn't.
- Targets are asked for as SLOs with
  percentiles and percentages, not adjectives.
- Consistency is asked per operation,
  not once for the whole system.
</quality_bar>
 
<output_format>
Numbered questions under the
group headings, and nothing else.
</output_format>
 
<process>
Ask all the questions in one message, then stop.
When I answer, write the requirements back as
functional, non-functional (with numbers) and out
of scope, mark anything still open [NEEDS SOURCE],
and end with a list of the assumptions you made.
</process>

<materials>
[paste the requirements from stage 1, with my answers]
</materials>
 
<context>
Team and operations: [team, e.g. 4 engineers, shared
on-call, no Kubernetes experience]. Budget: [budget, e.g.
under $5,000/month at launch]. The decision I'm least sure
about: [open question, e.g. how to build the home feed].
</context>
 
<task>
High-level design options for this system, so I
can choose one before the full design document.
</task>
 
<requirements>
- First a back-of-the-envelope estimate: average and peak
  QPS for reads and writes, storage per year, egress,
  with units at every step. Every option must cite it.
- 2–4 materially different options, differing in data
  store, fan-out or consistency on the key operation; one
  must be the simplest design that meets the numbers.
- For each: the read and write paths, what saturates first,
  how it meets each SLO, the monthly cost drivers, the
  operational load for this team, and what breaks at 10x.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing;
  mark cloud prices and quotas [VERIFY].
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- The arithmetic is right: 1 million
  requests a day is about 12 per second.
- Every component is justified by a
  number from the estimate or by an SLO.
- Each option names its bottleneck
  and its single points of failure.
- The recommendation says what would
  make you choose differently.
</quality_bar>
 
<output_format>
The estimate table (quantity | formula | inputs |
result | units); one section per option with a
Mermaid flowchart; a comparison table (option |
meets SLOs? | bottleneck | cost drivers | ops load |
breaks at 10x); a recommendation in under 100 words.
</output_format>
 
<process>
End with a list of the assumptions you
made. Then stop and wait for my choice: no
API, data model or failure analysis yet.
</process>

<materials>
[paste the requirements from stage 1]
[paste the chosen option, the estimate
table and the comparison from stage 2]
</materials>
 
<context>
[product and purpose, e.g. photo sharing; a production
design doc for review next week]. Stack: [stack, e.g.
AWS, Postgres, Redis, TypeScript; no Kubernetes]. Team:
[team, e.g. 4 engineers, shared on-call]. Reviewers:
[reviewers, e.g. two senior engineers and the CTO].
We chose [option, e.g. one Postgres primary with
read replicas, Redis cache-aside, a queue for
thumbnails] because [reason, e.g. it meets the SLOs
at a third of the cost of the sharded option].
</context>
 
<task>
The design document for the chosen option: what
the reviewers approve and the team builds from.
</task>
 
<requirements>
- SLOs per user journey, each with an SLI and
  a 30-day error budget; availability at
  [availability: 99.9% | 99.95% | 99.99%],
  justified by what the next nine would cost.
- Capacity estimates as a table with formula and units,
  average and peak; every major choice cites a number.
- Access patterns before the data model; consistency
  chosen per operation (strong, read-your-writes or
  eventual), with how the design provides each. [key
  operation, e.g. deleting a photo] needs
  [consistency: strong | read-your-writes | eventual].
- A failure-mode analysis in FMEA form for every component
  and arrow, slow-not-down dependencies included.
- Observability: RED metrics for every service, USE metrics
  for every resource, burn-rate alerts on the SLOs.
- Timeouts on every remote call; retries only on
  idempotent operations, with backoff and jitter.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing;
  mark cloud prices and quotas [VERIFY].
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every estimate recomputed a second
  way, with units on every line.
- Each SLI can be measured from
  metrics the design actually emits.
- No single point of failure without
  a stated reason to accept it.
- Every queue, cache and fan-out has a
  bound and a plan for when it fills.
- The monthly cost fits the budget.
</quality_bar>
 
<output_format>
Markdown, under [length, e.g. 6 pages], in these sections:
context, goals and non-goals; requirements and SLOs;
capacity estimates; API; access patterns and data model;
architecture (a Mermaid flowchart, and sequence diagrams
for the read and write paths); deep dives on the 3 hardest
parts; consistency table; failure-mode analysis (component
| failure mode | detection | user impact | mitigation |
recovery); observability and alerts; cost; rollout and
rollback; alternatives considered; open questions.
</output_format>
 
<process>
Ask me up to 3 questions first if anything
missing would change your answer; otherwise go
on. End with a list of the assumptions you made.
</process>

<materials>
<design>
[paste the design document]
</design>
<brief>
[paste the requirements and SLOs]
</brief>
</materials>
 
<context>
This is a fresh chat: you did not write this design.
It goes to review [when, e.g. on Thursday], where the
reviewers approve it, ask for changes or reject it.
</context>
 
<task>
A review of the design document before approval: what would
make it miss its SLOs, its budget or its operability.
</task>
 
<requirements>
- Check each requirement and SLO: met,
  unclear or not met, with the evidence.
- Recompute the estimates' arithmetic.
- Find single points of failure, unbounded
  resources (queues, caches, fan-out) and
  remote calls without timeouts.
- Check that the failure-mode analysis covers
  slow-not-down dependencies, zone loss, bad
  deploys, retry storms and hot keys.
- Score 1–5 on: requirements, estimates, estimates
  used, API, data model, storage choice,
  bottlenecks, consistency, failure handling,
  operations, cost, trade-offs, simplicity.
- Do not rewrite the design and do not praise it.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your review against:
- Every problem cites the section or number it comes from.
- Problems are ranked by user impact
  times likelihood, worst first.
- Each fix says what it costs: money, latency or complexity.
- If you found fewer than 5 problems,
  you say which checks came back clean.
</quality_bar>
 
<output_format>
A requirements check table; arithmetic corrections; the
scorecard; the ranked fixes (problem | evidence | fix |
cost); the questions the author must answer before approval.
</output_format>
 
<process>
End with a list of the assumptions you made.
</process>

Estimate capacity for [system, e.g. a URL shortener] from
[inputs, e.g. 10M DAU, 5 actions/user/day, 1 KB per item,
kept 5 years, 3x peak]: a table (quantity | formula | inputs
| result | units) for average and peak QPS, storage per year
and egress. Check it by recomputing each line with code.

<context>
System: [system, e.g. photo sharing with a home feed].
Users: [daily active users, e.g. 5M]. Behavior: [actions per
user per day, e.g. 50 feed views and 0.2 uploads]. Sizes:
[item sizes, e.g. 2 MB original, 200 KB feed size].
Retention: [retention, e.g. forever]. Peak:
[peak factor: 2x | 3x | 10x]. Copies: [replication, e.g. 3].
The estimate decides [decision, e.g. whether one
Postgres primary is enough and whether we need a CDN].
</context>
 
<task>
A back-of-the-envelope capacity estimate,
used to choose between designs.
</task>
 
<requirements>
- Average and peak QPS for reads and writes separately;
  storage per day and per year, with replication and index
  overhead; egress in bytes/s and bits/s; cache memory for
  the hot set; server count at 60% utilization.
- Units at every step; round to 2 significant figures.
- Per-server throughput is an assumption: state
  it and mark it [VERIFY] with a load test.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Per-day figures are divided by 86,400: 1M
  a day must come out near 12 per second.
- Bits and bytes are labeled;
  network figures are given in bits.
- Peak and average are separate columns.
- Every result ends in the design decision it supports.
</quality_bar>
 
<output_format>
A table: quantity | formula | inputs | result | units.
Then one line per result: the decision it changes.
</output_format>
 
<process>
Recompute every line a second way (or by running
code) and flag any line where the two differ.
End with a list of the assumptions you made.
</process>

Define the API for these use cases: [paste use
cases]. Endpoints with request and response JSON,
cursor pagination, idempotency keys on writes and
error codes. Check every use case maps to an
endpoint and every write can be retried safely.

<materials>
[paste the functional requirements and use cases]
</materials>
 
<context>
Clients: [clients, e.g. a web app and an iOS
app; third-party integrations next year]. Style:
[API style: REST with JSON | gRPC | GraphQL].
</context>
 
<task>
An API specification for these use cases,
reviewable before anyone writes code.
</task>
 
<requirements>
- Each endpoint: method and path, request
  and response JSON, status and error codes.
- Pagination: [pagination: cursor | offset],
  with a page-size limit.
- Every write that isn't naturally
  idempotent accepts an idempotency key.
- Versioning and rate limits stated.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every use case maps to at least one
  endpoint, and every endpoint to a use case.
- A client that retries any write after
  a timeout cannot create a duplicate.
- Each error response tells the
  client whether retrying can help.
</quality_bar>
 
<output_format>
A table (method | path | purpose | idempotent?),
then each endpoint's request and response as
JSON, or an OpenAPI 3 sketch in YAML.
</output_format>
 
<process>
Ask me up to 3 questions first if anything
missing would change your answer; otherwise go
on. End with a list of the assumptions you made.
</process>

List the access patterns for [system, e.g. a chat app]
(query | key | frequency | latency target | consistency),
compare 3 stores against them and recommend one. Default
to Postgres unless a pattern rules it out, and check that
every pattern is served by a key or index in your pick.

<materials>
[paste the access patterns, or the use
cases if you have no patterns yet]
</materials>
 
<context>
Data now and in 3 years: [data size, e.g. 200 GB
now, 5 TB in 3 years]. Team: [team, e.g. 4 engineers
who already run Postgres]. Cloud: [cloud, e.g. AWS].
</context>
 
<task>
A comparison of data stores for
this workload, so I can choose one.
</task>
 
<requirements>
- Start from the access patterns: query, key,
  frequency, latency target, consistency.
- Compare
  [stores: Postgres | DynamoDB | Cassandra | MongoDB] on fit
  to each pattern, consistency options, the scaling limit
  for this workload, operational burden and cost drivers.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing;
  mark vendor limits and prices [VERIFY].
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every access pattern is served by a
  key or index in the recommended store.
- The scaling limit is stated for
  this workload, not in general.
- The operational burden counts what this team already runs.
</quality_bar>
 
<output_format>
An access-patterns table; a comparison table (store
| each pattern | consistency | scaling limit | ops
burden | cost drivers); a recommendation, and the
change in workload that would make you switch.
</output_format>
 
<process>
End with a list of the assumptions you
made. Then stop: no schema until I choose.
</process>

For [system, e.g. a product catalog] with [load, e.g. 5,000
reads/s, 100:1 read:write, 50 GB data], design caching:
what, where, key format, TTL, invalidation on write,
stampede protection, hit rate and hot-set memory (show the
arithmetic). Check what happens when the cache is empty.

<materials>
[paste the access patterns and the current read path]
</materials>
 
<context>
Load: [load, e.g. 5,000 reads/s at peak, 100:1
read:write]. Data: [data, e.g. 50 GB; 10% of items get
90% of reads]. Freshness: [staleness allowed, e.g.
prices within 1 minute, descriptions within 1 hour].
</context>
 
<task>
A caching plan for this read path.
</task>
 
<requirements>
- Pattern:
  [pattern: cache-aside | read-through | write-through],
  and the layer for each item: CDN, app memory or Redis.
- Key format, TTL and invalidation
  on write for each cached item.
- Stampede protection (request coalescing or a lock)
  and the behavior when the cache is cold or lost.
- Expected hit rate and hot-set memory, with the arithmetic.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every cached item has a TTL and an invalidation
  path that meet its freshness limit.
- Losing the cache doesn't send the full
  read load to the database at once.
- The memory figure follows from
  the item size and the hot set.
</quality_bar>
 
<output_format>
A table: item | layer | key format | TTL |
invalidation | staleness allowed. Then the hit-rate
and memory arithmetic, then the cold-cache plan.
</output_format>
 
<process>
End with a list of the assumptions you made.
</process>

For these user journeys: [paste journeys], define
SLIs, SLOs and the 30-day error budget, then RED
metrics per service, USE metrics per resource, and
multiwindow burn-rate alerts. Check each SLI can
be measured from metrics we would actually have.

<materials>
[paste the component list or architecture
diagram, and the user journeys]
</materials>
 
<context>
On-call: [on-call, e.g. 4 engineers, a week each,
business hours only]. Tooling: [tooling, e.g.
Prometheus and Grafana, OpenTelemetry traces].
</context>
 
<task>
An SLO and observability plan for this system.
</task>
 
<requirements>
- Per user journey: the SLI, an SLO at
  [availability: 99.9% | 99.95% | 99.99%] or a latency
  percentile, and the 30-day error budget in minutes.
- Dashboards by the RED method for every service
  (rate, errors, duration) and the USE method for
  every resource (utilization, saturation, errors).
- Multiwindow, multi-burn-rate alerts on each
  SLO, as in the Google SRE workbook; say
  which page someone and which open a ticket.
- Traces across service boundaries;
  structured logs carrying a request ID.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every SLI is a ratio of good events to valid
  events, measurable from the listed metrics.
- Pages fire on symptoms (the SLO
  burning), not on causes (CPU high).
- The budget arithmetic is right: 99.9%
  over 30 days leaves about 43 minutes.
</quality_bar>
 
<output_format>
An SLO table (journey | SLI | SLO | error budget per 30
days); a dashboard list (service or resource | metrics); an
alert table (alert | windows | burn rate | page or ticket).
</output_format>
 
<process>
Ask me up to 3 questions first if anything
missing would change your answer; otherwise go
on. End with a list of the assumptions you made.
</process>

Estimate the monthly cost of this design by component,
and the cost per 1,000 requests: [paste design and
capacity estimate]. Show quantity × unit price per line.
Check no price is quoted from memory as fact: mark every
unit price [VERIFY] with the pricing page to check.

<materials>
[paste the design and the capacity estimate]
</materials>
 
<context>
Cloud and region: [cloud and region, e.g.
AWS eu-west-1]. Budget: [budget, e.g.
under $5,000/month at launch]. Pricing:
[pricing: on-demand | savings plans | spot for workers].
</context>
 
<task>
A monthly cost estimate for this design, to
compare with the budget and find the cost drivers.
</task>
 
<requirements>
- Cost by component: compute, storage, database,
  cache, egress, queues, observability.
- Each line: a quantity from the
  capacity estimate times a unit price.
- Mark every unit price [VERIFY] with
  the pricing page to check it on.
- Cost per 1,000 requests and per active user.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every quantity traces to the capacity estimate.
- Egress is included; it is the
  line people most often forget.
- The 3 biggest drivers are named, each
  with one change that would cut it.
</quality_bar>
 
<output_format>
A table: component | quantity | unit price |
monthly cost | assumption. Then the totals,
the unit costs and the top 3 drivers.
</output_format>
 
<process>
End with a list of the assumptions you made.
</process>

For this design: [paste design], write an FMEA-style
table (component | failure mode | detection | user impact
| mitigation | recovery) covering slow-not-down
dependencies, zone loss, bad deploys, retry storms, cache
stampedes, hot partitions and poison messages. Check
every box and arrow has a row; mark missing mitigations.

<materials>
[paste the design document and diagrams]
</materials>
 
<context>
SLOs: [SLOs, e.g. feed 99.9% available, p99 under
300 ms]. Recovery targets: [RPO and RTO, e.g. RPO
5 minutes, RTO 1 hour for losing a region].
</context>
 
<task>
A failure-mode analysis of this design: how it
behaves when each part fails, and what is missing.
</task>
 
<requirements>
- FMEA form: a row for each component and each arrow,
  for each failure that applies: crash, slow not down,
  zone loss, region loss, network partition, bad deploy
  or config, retry storm, cache stampede, hot partition,
  poison message, disk full, expired certificate,
  provider quota, clock skew, data corruption.
- Rate each row's severity, occurrence and detection
  from 1 to 10 (10 = hardest to detect) and rank by
  their product, the risk priority number.
- Separate the mitigations already in
  the design from the missing ones.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your analysis against:
- Every box and arrow in the diagram has at least one row.
- Each detection names a metric or
  alert the design actually has.
- Retries appear only where the operation is idempotent.
- The 5 worst rows each get a missing mitigation
  or a stated reason to accept the risk.
</quality_bar>
 
<output_format>
A table: component | failure mode | detection | user
impact | mitigation in design | missing mitigation |
recovery | S | O | D | RPN. Then the 5 worst, ranked.
</output_format>
 
<process>
End with a list of the assumptions you made.
</process>

Interview me on "[question, e.g. design a URL
shortener]" for a [level: mid | senior | staff] backend
role. Answer clarifying questions briefly, give no
hints, push on one hand-wave per stage, then score each
stage against what a strong candidate would have said.

<context>
I'm preparing for a system design interview for a
[level: mid | senior | staff] backend role at [company
type, e.g. a large consumer app]. My weak spots: [weak
spots, e.g. estimates and data modeling].
</context>
 
<task>
A 45-minute mock interview on "[question, e.g.
design a chat app]", then a scored debrief.
</task>
 
<requirements>
- Give me only the question at first. Answer
  clarifying questions briefly, as an
  interviewer would; don't suggest solutions.
- You can't see a clock: I'll type the elapsed
  minutes with each answer. Tell me when I'm
  behind the usual pace (requirements done by 10,
  high-level design by 25, deep dives by 40).
- Interrupt with one deep-dive
  question whenever I hand-wave.
- Score 1–4 on requirements, estimation,
  API and data model, high-level design,
  deep dives, trade-offs and communication.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering with the debrief, check it against:
- Each weakness quotes or paraphrases
  something I actually said.
- Each comes with what a strong
  candidate would have said instead.
- The scores follow the level I named, not a generic bar.
</quality_bar>
 
<output_format>
During the interview: short turns. At the end: a
score table (area | score | evidence | what strong
looks like), then the 3 things to practice first.
</output_format>
 
<process>
Start when I say "ready". End the debrief with a
list of the assumptions you made about the role.
</process>

Design Twitter.

<context>
I'm learning system design and want a design I can check.
A Twitter-like app; only the home timeline matters here.
In scope: post (text only), follow, home
timeline (newest first, 20 per page). Out
of scope: search, DMs, media, ranking, ads.
Scale: 50M daily active users; each opens the
timeline 10 times a day and posts 0.5 times.
Average 200 followers; a few accounts have 10M+.
</context>
 
<task>
A design for the home timeline at the depth of a
design document's core sections, with each
decision explained in one line so I learn from it.
</task>
 
<requirements>
- SLOs: timeline p99 under 200 ms; 99.9% available;
  a new post may take up to 10 s to reach followers.
- Capacity estimates with formula, inputs and units
  for timeline reads, posts and fan-out writes per
  second, and for timeline cache memory.
- Compare fan-out on write, on read and
  hybrid; handle the 10M-follower accounts.
- Failure modes in FMEA form for: losing a cache
  node, a fan-out backlog, a celebrity post.
- Never invent numbers, names, quotes or sources:
  write [NEEDS SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every estimate recomputed a second
  way; daily counts divided by 86,400.
- Every component justified by an estimate or an SLO.
- The fan-out choice cites the follower
  numbers and the 10 s freshness target.
- Each failure mode has detection,
  impact, mitigation and recovery.
</quality_bar>
 
<output_format>
1. Capacity table: quantity | formula
   | inputs | result | units.
2. API for post, follow and timeline (cursor pagination).
3. Data model for posts, follows and precomputed timelines.
4. Fan-out trade-off table and the choice.
5. Mermaid sequence diagrams for posting and for reading.
6. Failure-mode table.
7. What breaks first at 10x.
</output_format>
 
<process>
Ask me up to 3 questions first if anything
missing would change your answer; otherwise go
on. End with a list of the assumptions you made.
</process>

No questions; assumptions are at the end.
 
1. Capacity (average; peak = 3x)
Quantity       | Formula             | Result
Timeline reads | 50M x 10 / 86,400   | ~5,800/s
Posts          | 50M x 0.5 / 86,400  | ~290/s
Fan-out writes | 25M x 200 / 86,400  | ~5,800/s
Timeline cache | 50M x 200 IDs x 8 B | ~80 GB raw
 
4. Fan-out: hybrid
On write for accounts under 100k followers: the 10 s target
allows asynchronous workers. On read for the few accounts
with 10M+ followers, merged into the timeline when it is
read. Peak fan-out is ~17,000 inserts/s: about 9 workers.
 
6. Failure modes
Fan-out backlog | detection: oldest queued post > 10 s |
impact: stale timelines | mitigation: autoscale workers,
fan out to recently active followers first | recovery:
drain the queue, then backfill the skipped followers
 
Assumptions:
1. The timeline cache keeps 200 post IDs per user.
2. Peak traffic is 3x the average.
3. Users inactive for 30 days are skipped at fan-out and
   rebuilt on their next visit.
4. One worker handles about 2,000 inserts/s.

Fan-out writes are wrong: 25M posts x 200 followers = 5
billion inserts a day, about 58,000/s average and 174,000/s
at peak, not 5,800/s. Redo the capacity table by running
the arithmetic in code, then update only what depends on
it: the worker count, the write load on the timeline cache,
the fan-out deep dive and the fan-out-backlog failure mode.
Move assumption 3 (skip inactive users) into the design,
with an estimate of the load it removes; mark the share of
inactive users [NEEDS SOURCE]. List what you changed.

Recompute every estimate step by step with units, then
list each design decision and the number that justifies
it. Flag any component no number justifies.

Walk one request through the write path and one through
the read path, naming every network hop, its expected
latency and what happens if that hop times out.

Which dependency in this design, if it became 10x slower
but stayed up, would hurt most? Trace the effect and fix
it.

Cut the monthly cost by half while keeping the SLOs. What
would you change and what risk does each change add?