System Design & Interviews
System design is the vocabulary senior engineers use to argue about trade-offs before the code exists. It is also the interview format that most consistently separates mid-level from senior candidates. This track treats system design as a working discipline, not an interview-cramming exercise: the goal is to make you comfortable sketching a design on a whiteboard, defending the parts that matter, and admitting the parts that don't. If you can do that, the interview format takes care of itself.
What this track covers
The fundamental building blocks — load balancers, caches, queues, replicated and sharded databases, CDNs — and the reasoning frameworks that turn them into designs: capacity estimation, consistency vs availability trade-offs, hot-key mitigation, back-pressure. Then walk-throughs of classic problems: URL shortener, feed ranking, chat, rate limiting, notification systems.
Who this is for
Mid-level engineers preparing for a senior or staff-level interview, and working engineers who want to be more useful in design reviews on their own team.
Prerequisites
- Have shipped at least one production service end-to-end
- Comfortable with basic distributed-systems vocabulary (leader/follower, quorum, eventual consistency)
- Familiar with at least one queue (Kafka, RabbitMQ, SQS) and one cache (Redis, Memcached)
- Willing to sketch on a whiteboard or tablet — this is a diagram-first discipline
Recommended learning order
// beginner
Start with the interview-preparation guide to get a feel for the format. Then work through capacity estimation and the URL-shortener design as a warm-up — it exercises most of the primitives (hashing, storage layout, cache, rate limiting) in one small problem.
// intermediate
Move to designs that force explicit trade-offs — a news feed (write-fanout vs read-fanout), a chat system (delivery guarantees, ordering), a rate limiter (token bucket vs leaky bucket). Study one real paper — the Dynamo or the Kafka paper — properly.
// advanced
Multi-region designs, active-active vs active-passive, geo-partitioning, consensus protocols at a conceptual level (Raft), and the operational concerns that actually decide these designs in production — deployment blast radius, on-call load, capacity planning cost.
Common mistakes to avoid
- Jumping to a specific database (Cassandra! DynamoDB!) before defining the access pattern
- Ignoring capacity estimation — 'let's use Kafka' is not an answer, '30k events/s peak, 90-day retention' is
- Drawing a beautiful diagram but never talking about failure modes
- Adding a cache to every layer without asking what the invalidation strategy is
- Optimising for the interview answer sheet instead of thinking out loud — interviewers hire for the second, not the first
Career relevance
System-design performance is the single largest factor in senior and staff-level offer levelling at every major tech company. Even outside interviews, the vocabulary this track builds is exactly what makes an engineer useful in an architecture review.