System Design
Engineer
Roadmap

Every system design conversation starts with the request path. Understand DNS resolution, TCP/IP, HTTP/HTTPS, TLS handshakes, and the client-server model deeply. Learn how load balancers, reverse proxies, and CDNs sit in that path. Study the difference between latency and throughput, and why every design decision is really a trade-off between the two. This is the vocabulary every other phase depends on.

Every distributed system is a set of services agreeing on how to talk to each other. Master REST API design: resources, status codes, idempotency, pagination, versioning. Learn GraphQL for flexible client queries and gRPC for fast internal service-to-service calls using Protocol Buffers. Understand WebSockets and Server-Sent Events for real-time communication. Know when to pick sync request/response versus async messaging — this decision shapes your entire architecture.

Most system design interviews hinge on the data model. Master relational databases: normalization, indexing, query optimization, ACID transactions, joins at scale. Learn NoSQL categories — document stores (MongoDB), key-value (Redis, DynamoDB), wide-column (Cassandra), and graph (Neo4j) — and when each fits. Understand indexing strategies (B-tree, hash, composite) and how they trade write speed for read speed. Know the SQL-vs-NoSQL decision cold; interviewers ask for it constantly.

Scalability is the heart of system design. Master vertical vs horizontal scaling and why horizontal wins at scale. Learn load balancing algorithms (round robin, least connections, consistent hashing) and how to keep services stateless so any instance can serve any request. Study rate limiting (token bucket, sliding window) to protect systems from overload. Understand horizontal partitioning as the pattern behind almost every large-scale design you'll be asked to whiteboard.

Caching is the fastest way to make a slow system feel instant. Master Redis and Memcached for in-memory caching, cache invalidation strategies (write-through, write-behind, cache-aside), and CDN edge caching. On the database side, learn replication (leader-follower, multi-leader) for read scaling and sharding/partitioning (range-based, hash-based, geo-based) for write scaling. Understand read replicas and connection pooling as the first tools you reach for before rearchitecting anything.

Not everything needs an immediate response. Master message queues (RabbitMQ, SQS) for decoupling producers from consumers and pub/sub systems (Kafka, Google Pub/Sub) for fan-out at scale. Understand event-driven architecture, event sourcing, and the outbox pattern for reliable messaging alongside database writes. Learn delivery guarantees — at-most-once, at-least-once, exactly-once — and why "exactly-once" is mostly a marketing term. Async messaging is what lets systems absorb traffic spikes gracefully.

Splitting a monolith into services introduces distributed systems problems you didn't have before. Learn microservices patterns: API gateways, service discovery, circuit breakers, and the saga pattern for distributed transactions. Master the CAP theorem and what it actually forces you to trade off. Study consensus algorithms (Raft, Paxos) and how they underpin leader election in distributed databases. Understand eventual vs strong consistency — and how to explain, precisely, which one a given feature needs.

At scale, hardware fails, networks partition, and services crash — design for it, don't hope around it. Learn redundancy and failover (active-active, active-passive), circuit breakers and retries with backoff, and graceful degradation. Master observability: metrics with Prometheus, structured logging, and distributed tracing with OpenTelemetry to debug a request across a dozen services. Study SLOs, SLAs, and error budgets — the language reliability gets measured in.

Theory only sticks once you've applied it end to end. Practice designing well-known systems from scratch: a URL shortener, a rate limiter, a chat application (WhatsApp-style), a news feed (Twitter/Instagram-style), a ride-sharing dispatch system (Uber-style), and a video streaming platform (YouTube/Netflix-style). For each, work through requirements, capacity estimation, high-level design, deep dives, and bottlenecks — the exact structure interviewers expect.

System design interviews test four things: requirement clarification (functional vs non-functional, asking the right questions first), capacity estimation (back-of-envelope math for storage, bandwidth, and QPS), high-level design (the boxes-and-arrows architecture), and deep dives (defending one component under interviewer pressure). Practice low-level design (LLD) too — class diagrams and design patterns for a single service. Do at least 15 timed mock interviews before real ones. Document 3–5 designs on GitHub with diagrams and trade-off write-ups.