System Design¶
Design systems the way production engineers do: start with goals and constraints, make trade-offs explicit, draw clear diagrams, then prove the critical path with code.
This course is for working software engineers and people who want to become software engineers. You do not need to be a cloud architect first. You need curiosity about how requests, data, and failures move through a system.
Who this is for¶
| You are… | You will practise… |
|---|---|
| Aspiring software engineer | Turning vague features into APIs and data models |
| Backend / full-stack engineer | Scaling paths, consistency, and failure modes |
| DevOps / platform engineer | Seeing services as products with SLOs and blast radius |
| Interview candidate | Structured design conversations with evidence |
What you will learn¶
- Clarify functional and non-functional requirements before drawing boxes
- Estimate capacity with simple, defensible maths
- Choose architecture styles for the problem — not fashion
- Trace a request from client through DNS, CDN, load balancer, and service
- Explain trade-offs (latency vs consistency vs cost) in plain language
- Implement thin but real paths in Python so designs stay honest
Course structure¶
| Part | Focus | Status |
|---|---|---|
| A · Foundations | Design process, quality attributes, styles, request path | Modules 1–4 ready |
| B · Building blocks | Storage, cache, messaging, APIs, resilience | Modules 5–9 ready |
| C · Classic systems | Shortener, feed, uploads, search | Modules 10–13 ready |
| D · Realtime | Chat, notifications, collaboration, capstone | Modules 14–17 ready |
Start here¶
- How to design a system — the thinking process
- Quality attributes and trade-offs — what “good” means
- Application architecture styles — monolith to events
- Client, edge, and service path — where a request travels
- Data storage — access patterns and engines
- Caching — layers, TTL, stampede control
- Messaging and async — queues and idempotency
- APIs and communication — contracts and timeouts
- Observability and resilience — SLOs and failure modes
- URL shortener — redirect-optimised design
- News feed / timeline — fan-out trade-offs
- File / media upload — direct upload pipelines
- Search / autocomplete — indexes and suggest
- Realtime chat — WebSockets and durable fan-out
- Notifications and presence — heartbeats and routing
- Collaborative and streaming patterns — OT/CRDT intuition
- Capstone — collaboration board — integrate the course
See the roadmap for the full journey.
How each tutorial works¶
Every lesson follows the same arc:
Requirements → Trade-offs → Architecture (diagrams) → Python lab → Interview check
Diagrams are first-class. Labs use Python so you can run and break things on your machine.
Prerequisites¶
- Comfortable with HTTP (methods, status codes, JSON)
- Can write small Python scripts
- Basic SQL ideas (tables, primary keys)
- Git installed
All course labs run with Python alone. Docker/Redis are optional upgrades for portfolio demos.