← Library
01
02
03
04
05
06
Course · by Yash Tiwari
System Design: From first principles to real systems
How to design software that scales, stays up and can be changed safely: the building blocks, the trade-offs behind them, and worked case studies.
Foundations
The language and the maths you need before drawing any boxes.
- 1.1What system design really isSoon
- 1.2Requirements and back-of-the-envelope estimationSoon
- 1.3Latency, throughput and availabilitySoon
- 1.4CAP, PACELC and consistency modelsSoon
- 1.5Scaling up, scaling outSoon
Building blocks
The parts every large system is assembled from.
- 2.1Load balancingSoon
- 2.2CachingSoon
- 2.3CDNs and edge deliverySoon
- 2.4Choosing a database: SQL, NoSQL and friendsSoon
- 2.5Indexing and storage enginesSoon
- 2.6ReplicationSoon
- 2.7Partitioning and shardingSoon
- 2.8Consistent hashingSoon
- 2.9Message queues and streamsSoon
- 2.10Rate limitingSoon
Distributed systems
What changes when one machine becomes many.
- 3.1Time, clocks and orderingSoon
- 3.2Consensus, in plain wordsSoon
- 3.3Idempotency, retries and timeoutsSoon
- 3.4Distributed transactions and sagasSoon
- 3.5Event-driven architectureSoon
- 3.6Designing for failureSoon
APIs and communication
How services talk, and how to keep that conversation stable.
- 4.1REST, gRPC and GraphQLSoon
- 4.2API design and versioningSoon
- 4.3Pagination, bulk operations and webhooksSoon
Reliability and operations
Keeping it running, and knowing when it is not.
- 5.1Observability: logs, metrics, tracesSoon
- 5.2SLOs and error budgetsSoon
- 5.3Capacity planningSoon
- 5.4Safe deployments and rollbacksSoon
- 5.5Security basics for system designersSoon
Case studies
Putting the pieces together on problems you have seen before.
- 6.1Design a URL shortenerSoon
- 6.2Design a rate limiterSoon
- 6.3Design a news feedSoon
- 6.4Design a chat systemSoon
- 6.5Design a notification systemSoon
- 6.6Design search autocompleteSoon