Foundation curriculum
System Design
System design means choosing how software meets its real workload and reliability needs. Start with requirements, measure the limiting boundary, and add complexity only when it solves a demonstrated problem.
Recommended sequence
Decisions before diagrams.
This is not an interview-pattern catalog. The first lessons connect requirements to workload measurements, then ask when more capacity or different routing actually helps. Read the published lessons in order, or enter at a specific design question.
Open the system-design learning path- Published
- 3 lessons are ready to read.
- Planned
- The remaining 7 topics have no article routes yet.
- Approach
- State assumptions, compare tradeoffs, and measure the system before increasing complexity.
Published and planned
Ten concepts in learning order
- System Design Starts With Requirements and ConstraintsRead lesson →
- Latency, Throughput, Capacity, and BottlenecksRead lesson →
- Scaling, Load Balancing, and Stateless ServicesRead lesson →
- Monoliths, Modular Monoliths, and MicroservicesPlanned · not yet published
- Caching, CDNs, and Cache InvalidationPlanned · not yet published
- Database Scaling, Replication, and PartitioningPlanned · not yet published
- Consistency, Availability, and Distributed TradeoffsPlanned · not yet published
- Queues, Events, and Asynchronous ProcessingPlanned · not yet published
- Timeouts, Retries, Idempotency, Rate Limits, and BackpressurePlanned · not yet published
- Observability, High Availability, and Designing for FailurePlanned · not yet published
Published lessons are links. Planned lessons are deliberately not clickable.
Connected foundations
Useful before you begin
You do not need to complete another path first. These published lessons explain the application, data, and infrastructure boundaries used here: