Skip to content
Insight CodeAcademy

System Design

What is System Design?

System design is the practice of deciding how the components of a software system fit together to meet requirements for scale, latency, availability and cost. Unlike coding problems, design problems have no single correct answer — the skill being tested is whether you can state the trade-offs behind your choices and defend them under new constraints.

System design interviews are not a memory test, though they are often prepared for like one. Reciting a diagram of Twitter's architecture fails the moment the interviewer changes a constraint. This guide covers the building blocks first, then the judgement for combining them.

Fundamentals

The vocabulary and mental models everything else builds on.

  • Vertical vs horizontal scaling
  • Latency, throughput and bandwidth
  • Availability, reliability and fault tolerance
  • The CAP theorem and what it actually constrains
  • Consistency models: strong, eventual, causal
  • Back-of-the-envelope estimation

Articles on fundamentals

Networking and delivery

How a request reaches your system, and what sits in front of it.

  • DNS resolution
  • HTTP, HTTPS and connection reuse
  • Load balancing algorithms
  • Layer 4 vs layer 7 load balancing
  • Reverse proxies and API gateways
  • Content delivery networks
  • WebSockets, long polling and server-sent events

Data storage

Where the hard trade-offs live. Most design interviews turn on this section.

  • Relational databases and B-tree indexing
  • SQL vs NoSQL and how to choose
  • Leader-follower and multi-leader replication
  • Sharding strategies and hotspots
  • Consistent hashing
  • ACID and BASE
  • Transaction isolation levels
  • Object and blob storage

Articles on data storage

Caching

The highest-leverage optimisation available, and the easiest one to get subtly wrong.

  • Cache placement: client, CDN, application, database
  • Cache-aside, read-through, write-through, write-back
  • Eviction policies: LRU, LFU, FIFO
  • Cache invalidation strategies
  • Thundering herd and cache stampede
  • Redis vs Memcached

Asynchronous systems

Decoupling producers from consumers, and the failure modes that come with it.

  • Message queues and brokers
  • Publish-subscribe
  • Kafka partitions, offsets and consumer groups
  • Delivery guarantees and idempotency
  • Dead letter queues and retry strategies
  • Stream processing

Architecture and operations

How systems are structured, deployed and kept alive.

  • Monolith vs microservices
  • Service discovery
  • REST, GraphQL and gRPC compared
  • Rate limiting algorithms
  • Circuit breakers and bulkheads
  • Logs, metrics and distributed tracing
  • Consensus and leader election

Design case studies

Full designs worked end to end, the same way you would in an interview.

  • URL shortener
  • Rate limiter
  • News feed
  • Chat system
  • Ride-hailing service
  • Video streaming platform
  • Distributed search
  • Notification system

Learn all of this in one structured course

Everything in the DSA course, plus a full System Design curriculum that covers the building blocks of large-scale systems and the judgement to combine them. Built for engineers targeting senior, staff and architect roles.

View the DSA + System Design course

System Design: frequently asked questions

How do I start preparing for a system design interview?
Learn the building blocks before attempting full designs. Get comfortable with load balancing, caching, database replication and sharding, message queues and the CAP theorem first. Only then work through case studies, because a case study is just a particular arrangement of those blocks.
How much experience do I need for system design interviews?
System design rounds usually begin at the mid-level and become decisive at senior and above. One to two years of professional experience is the practical floor, because the discussion assumes you have deployed something and seen it behave badly.
What structure should I follow in a system design interview?
Clarify requirements and scope, estimate the scale, define the API, sketch a high-level design, then go deep on the two or three components the interviewer probes. State trade-offs explicitly as you go. Ending with a coherent design you can defend beats a more complex one you cannot.
Is system design only about scale?
No. Scale is the most visible axis, but availability, consistency, cost, operational complexity and failure behaviour matter just as much. A design that scales but cannot be debugged at three in the morning is a bad design.

Ready for the role you're aiming for?

Pick the course that matches where you are and start this week.

Explore coursesBook a free call

Free · 15 min · No cost, no spam