System design is the discipline of choosing how a software system is laid out at the level above any single codebase: which services exist, how they talk, where the data lives, what fails first when load doubles. The category is now a standard part of senior-engineer interviews at FAANG and most well-funded startups, but the underlying skill is the same one staff engineers use to plan a quarter's work.
Most courses in this category cover the same building blocks because the same ones keep showing up in real systems: load balancers, replicated databases, caches, message queues, idempotent APIs, sharding strategies, eventual consistency. The differences come from how each course frames trade-offs and how deep into a specific technology (Kafka, PostgreSQL replication, Cassandra) the lectures go.
What you'll work with in these 52 courses
- Scalability primitives: horizontal scaling, sharding, replication, CAP theorem
- Caching layers: Redis, Memcached, CDN edge caching, cache invalidation patterns
- Messaging: Kafka, RabbitMQ, NATS, SQS — at-least-once vs exactly-once
- Data modeling: SQL vs NoSQL, OLTP vs OLAP, time-series databases
- Distributed-system patterns: leader election, consensus, idempotency, sagas
- Real interview problems: design Twitter, Uber, WhatsApp, a URL shortener, a rate limiter
The skill set transfers across companies because the underlying primitives don't change. The system you design for a hypothetical "design Instagram" question maps directly onto how Stripe handles webhooks, how Slack delivers messages, or how Cloudflare propagates cache invalidations.
