Free system design template
Architecture review
Today's design on the board with the questions a review asks as notes, and criteria for the targets you must keep.
It opens with this template loaded and runs in your browser. You don't need an account to use it; a free account saves your work and exports it.
The job it does
Before a big launch or a design review meeting: show the current system, its limits and what you propose to change. It comes with its own checks, so after you change it you can see at a glance that it still does the job.
What's inside
This is the template exactly as the System Design Studio opens it, read-only. Open it to run it, change it and export it.
- 9 parts
- Traffic 600 req/s, peak 1,500 req/s
- 80% reads, 20% writes
Before a launch or a design review: put today's system on the board, write the questions a review asks as notes, and turn the targets you must keep into criteria. Run it to see where it stands today, then change one thing at a time and compare the runs (Results → history).
This one is Mangrove Market's online orders: 600 requests a second, 1,500 at the Friday peak. Pages must stay under 300 ms at p95, errors under 1%, every order stored twice, for at most $2,500 a month.
Replace the parts and the notes with your own system.
- p95 latency ≤ 300 ms
- Error rate ≤ 1%
- Every database has a copy
- Costs ≤ $2,500/month
Parts
- Web client: Web client
- Mobile app: Mobile app
- CDN: CDN
- Load balancer: Load balancer
- App server: App server, 4 replicas, Medium (2 vCPU, 4 GB)
- Cache: Cache, Medium (2 vCPU, 4 GB)
- DB primary: DB primary, 2 replicas, Medium (2 vCPU, 4 GB)
- Queue: Queue
- Worker: Worker, 2 replicas, Medium (2 vCPU, 4 GB), idempotency keys on
Arrows
- Web client → CDN
- Web client → Load balancer
- Mobile app → Load balancer
- Load balancer → App server
- App server → Cache
- App server → DB primary
- App server → Queue
- Queue → Worker
- Worker → DB primary
- Review questions:; 1. What breaks first at 2× the peak?; 2. What happens when the cache is cold?; 3. Which parts are single points of failure?
- Decisions to record:; • why a queue for confirmations; • why no read replica yet
- Owner per part, and the alert that pages them.
The lesson behind it
Learn why it works, with a podcast and a quiz for each lesson.
More system design templates
Capacity plan
Expected peak traffic, a sized design and Find my limit, with headroom and cost per month as criteria.
Incident post-mortem diagram
The system as it was, the failing part in a red zone, a timeline in notes and a criterion that proves the fix.