Backend architecture curriculum
Learn system design by running it
A calm, browser-based path from first request-response flow to production failure modes. Learn the vocabulary, place the components, then watch the system behave under traffic.
Server, database, latency, and first bottlenecks.
Load balancers, caches, replicas, queues, and edge delivery.
Incidents, post-mortems, counterfactuals, and on-call handovers.
Start with the request path
System design becomes less abstract when you can see one request move through servers, databases, caches, queues, and edge systems. Mutexmachine starts with a small backend and gradually adds the failure modes that make production systems interesting.
The recommended curriculum order begins with request-response basics, horizontal scaling, and caching. From there it moves into database scaling, contention, asynchronous work, media delivery, high availability, graceful degradation, incident response, realtime systems, and ingestion pipelines.
Request-response basics
Follow one user request through compute and storage before adding more moving parts.
Horizontal scaling
See why extra servers need traffic distribution, not just more boxes on a diagram.
Caching repeated reads
Watch cache warm-up reduce database pressure, and learn why timing matters.
Learn by consequence
Every component has cost and capacity. Every SLA has uptime, latency, and budget targets. A design that looks complete can still fail if it warms too slowly, overloads the database, builds queue depth, or spends the entire budget before an incident arrives.
That feedback loop is the reason to simulate. You see the metric, choose a response, and then study the post-mortem instead of guessing whether the architecture was good.
Capacity
Each tier can saturate independently, so the bottleneck is a moving target.
Cost
A system can survive traffic and still miss the contract by overspending.
Incidents
Timed decisions turn static architecture knowledge into operational judgment.
A learning loop that mirrors production
The app does not ask you to memorize a perfect answer. It asks you to make a design, deploy it, observe what breaks, and explain what you would change. That is closer to how system design skill grows in real engineering teams.
Post-mortems name the root cause, contributing factors, impact, and what would have helped. Timelines let you branch from a completed run and test whether the advice actually changes the outcome.
Design
Choose components under budget and SLA constraints.
Simulate
Run traffic and watch load, latency, errors, queue depth, and spend move.
Reflect
Read the post-mortem and rerun the counterfactual.
Suggested path
If you are new, start with the guided basics. After that, move into the scenario library by pressure type: read-heavy systems, write-heavy systems, async work, reliability, realtime traffic, and ingestion pipelines.
If you already know the vocabulary, skip straight to the scenarios. The simulator will still show you where your instincts are strong and where they are only diagram-deep.
1. Guided basics
Seven short lessons introduce the components one by one.
2. Scenario practice
Run full traffic curves with budgets, SLAs, and incident pressure.
3. On-call mode
Inherit a live architecture mid-failure and stabilize what someone else built.
FAQ
What should I learn first in system design?
Start with the request path: client, server, database, latency, and throughput. Then add load balancing, caching, read replicas, queues, and reliability patterns.
Can I learn system design without drawing diagrams?
Diagrams help, but they are not enough. Running a design under traffic teaches the consequences behind the diagram.
Is Mutexmachine beginner-friendly?
Yes. The guided basics introduce components gradually, and the glossary explains infrastructure terms as they appear.
How is this different from reading a system design guide?
A guide explains patterns. Mutexmachine lets you apply those patterns, watch them fail or hold, and review a post-mortem.