English | 简体中文
A practical system design checklist for backend engineers who want a reusable framework for:
- system design interviews
- architecture reviews
- service design docs
- production readiness discussions
- backend / distributed-systems self-study
This repo is intentionally checklist-first: concise enough to use during design discussions, but detailed enough to expose real engineering tradeoffs.
- Project page: happysnaker.github.io/system-design-checklist
- Proof before payment: support/#proof-before-payment
- 10-second support router: support/#sponsor-router
- Sponsor prospect pipeline: docs/sponsor-prospect-pipeline.md — route system-design / architecture-review customers to the right proof, CTA, support note, and guardrail before paying or asking for review
Want a version you can adapt for your own interviews, RFCs, or architecture reviews? Click Use this template on GitHub and turn it into your own working copy.
If you want the blunt first-impression version applied to your own GitHub / README / portfolio page, I offer a ¥29.9 quick read and a ¥99 async pass on the review page.
If you want to skip the back-and-forth, start from a filled email template: ¥29.9 quick read · ¥99 async review
Route system-design / architecture-review customers through the sponsor prospect pipeline first so the ask maps to proof, CTA, support note, and guardrail before payment. Then use the sponsor conversion scorecard to classify Hot / Warm / Nurture / No-send before asking for support or paid review.
Public issue privacy guardrail: do not paste private logs, credentials, QR codes, payment screenshots, internal URLs, or raw live integration output in public issues; use the intake replies first.
- Project page: happysnaker.github.io/system-design-checklist
- a reusable checklist for backend / distributed-systems design
- a lightweight design-doc template you can fill in quickly
- a short tradeoff sheet for architecture reviews
- review prompts for interviews and technical design discussions
- a one-page answer sheet you can keep beside you during interviews and reviews
- worked examples that show how to apply the checklist in practice
A lot of "system design" material is either:
- too high-level to help you make implementation decisions, or
- too interview-gimmicky to be useful in real engineering work
This repo aims for a better middle ground:
- practical, not performative
- backend-oriented, not whiteboard-only
- useful in interviews and real service design
- focused on tradeoffs, failure modes, and operations
- it is short enough to use during an interview or review
- it pushes on failure modes, tradeoffs, and operations instead of hand-wavy diagrams
- it includes templates and worked examples, not just a topic list
Use this checklist when you need to design or review a service.
- Clarify scope and constraints
- Sketch the request / event flow
- Walk the checklist section by section
- Write down explicit tradeoffs and risks
- End with operations and rollout readiness
flowchart TD
A[Clarify requirements] --> B[Estimate scale]
B --> C[Choose APIs and boundaries]
C --> D[Model data and storage]
D --> E[Design read and write paths]
E --> F[Handle cache, queue, and consistency tradeoffs]
F --> G[Plan reliability and observability]
G --> H[Review security, rollout, and operations]
Use the checklist to keep your answer structured so you don't forget scale, failure modes, consistency, or operations.
Use the checklist as a review aid when you want to challenge assumptions, surface tradeoffs, and find the parts that will be painful to operate later.
Use the checklist and template together when writing a lightweight design doc for a new service, feature, or subsystem.
- What is the primary user or business outcome?
- What is explicitly in scope and out of scope?
- What are the latency, throughput, durability, and consistency expectations?
- Is this an online serving system, an async pipeline, or a hybrid?
- What assumptions are we making that could break later?
- What are the functional requirements?
- What are the non-functional requirements?
- What availability target matters here?
- What data-loss tolerance exists?
- Are there regulatory, privacy, or audit constraints?
- Are there cost or team-ownership constraints?
- QPS / RPS expectations?
- Read/write ratio?
- Peak traffic multiplier?
- Storage growth over 6–12 months?
- Hot-key, tenant-skew, or burstiness risks?
- Cross-region or cross-AZ requirements?
- What are the service boundaries?
- Is REST, RPC, async messaging, or a hybrid more appropriate?
- What request/response contracts must remain stable?
- What idempotency guarantees are required?
- How are pagination, filtering, retries, and errors handled?
- What ownership boundary exists between this service and upstream/downstream systems?
- What are the core entities and relationships?
- What access patterns dominate?
- Does relational storage fit, or do we need KV/document/search/time-series storage?
- Which indexes are required for expected queries?
- What are the partitioning / sharding keys?
- What schema evolution or migration risks exist?
- What happens on a normal read request?
- What can be cached?
- Where should caching live: client, CDN, service, or storage-side?
- What happens on cache miss, stampede, or hot key?
- How is degraded read behavior defined?
- What happens on create / update / delete?
- Is synchronous confirmation required?
- Where can buffering or queuing help?
- What are the retry semantics?
- What prevents duplicate effects?
- What is the failure mode if downstream work partially succeeds?
- Do we need a queue, stream, or event bus?
- What ordering guarantees actually matter?
- What is the retry strategy?
- Is a dead-letter queue needed?
- How are poison messages detected and handled?
- How will operators replay or backfill safely?
- Where do we need strong consistency vs eventual consistency?
- What invariants must never be violated?
- How are race conditions prevented or tolerated?
- What deduplication / idempotency key is required?
- How do transactions, locks, or compensating actions fit here?
- What are the main failure domains?
- What happens if a dependency times out or returns errors?
- Where do we need timeouts, backoff, circuit breaking, or bulkheads?
- What is the blast radius of bad deploys or malformed traffic?
- What graceful-degradation path exists?
- How do we recover after partial outage or data backlog?
- What logs are necessary for incident response?
- What metrics define healthy behavior?
- What traces or spans will explain latency?
- Which SLIs / SLOs matter?
- What dashboards and alerts should exist on day one?
- What runbooks or playbooks are needed?
- What authn / authz checks are required?
- What secrets and sensitive data exist?
- Is PII encrypted and access-controlled appropriately?
- What rate limiting or abuse controls are needed?
- What auditability requirements exist?
- What data-retention or deletion obligations exist?
- How will this be deployed safely?
- Can it be canaried or rolled out progressively?
- Are schema / config / code changes compatible across versions?
- What rollback strategy exists?
- How will we validate success after launch?
- What is the simplest version that still solves the real problem?
- Which assumption is most likely to fail first?
- Where are we over-engineering?
- What will be painful to operate six months from now?
- What should we explicitly defer to a later phase?
docs/service-design-template.md— lightweight design-doc structuredocs/common-tradeoffs.md— common backend tradeoffs worth calling out explicitlydocs/review-questions.md— practical review prompts for interviews or architecture reviewsdocs/examples/url-shortener.md— worked example for a classic read-heavy interview problemdocs/examples/notification-service.md— worked example for an async, fan-out-heavy backend system
If you want to see the checklist applied end-to-end instead of just reading prompts:
- URL shortener example — request flow, storage model, hot-key/cache behavior, and operational tradeoffs
- Notification service example — event ingestion, fan-out workers, retries, preferences, and provider failure handling
If you want a shorter prompt sheet that you can keep open during an interview or design review:
docs/system-design-answer-sheet.md— compact English versiondocs/system-design-answer-sheet.zh-CN.md— 简体中文版本
This repo is especially useful if you are:
- preparing for backend / infrastructure / system design interviews
- reviewing designs for APIs, services, or internal platforms
- trying to build stronger distributed-systems intuition
- mentoring engineers who need a repeatable design framework
If you like this repo, you may also want:
backend-engineer-checklist— practical backend growth roadmapgo-service-starter— minimal production-minded Go HTTP service starter
If this repo saves you time, consider:
- starring the repo
- sharing it with other backend engineers
- linking it in interview-prep lists or internal onboarding docs
- supporting ongoing open-source work via the support page: happysnaker.github.io/support
- current cross-project sponsor brief: Sponsor one-pager
- sponsor / paid-support intake replies: share-kit intake replies
- sponsor conversion scorecard: Hot / Warm / Nurture / No-send before asking for support or paid review
- deploy-read sample before paying: happysnaker.github.io/review/deploy-read-sample
- shortest support thread: If system-design-checklist helped, here is the shortest support path
If this checklist helped you structure an interview answer or a design doc, small support is especially appreciated.
If you want lightweight async feedback on a public GitHub profile, README, design-doc page, or portfolio page, details are also available on the support page.
Typical support fit:
- ¥9.9 — if one section helped you avoid a weak design answer
- ¥19.9 — if it helped a full interview loop or architecture review
- best payment note —
system-design-checklist - fastest path — tip directly if the checklist helped; use ¥29.9 / ¥99 only if you want feedback back
- ¥99 — if you want async feedback on your own public design-doc / README / profile packaging
MIT