System design is the skill of turning a vague idea, like building something similar to TinyURL, into a working plan. You decide what it does, how big it must be, which pieces it needs and what you give up with each choice. This course teaches it one concept per chapter, so you never face a wall of theory.
Every chapter has a diagram, an everyday example, worked numbers, code you can run, common mistakes and exercises with hidden answers. The first part covers the interview routine, estimation and API design. Then come scalability, networking, databases, caching, queues and distributed systems, followed by eleven head-to-head trade-offs you can quote in an interview.
It ends with fifty full case studies, from a URL shortener to a stock exchange matching engine. Each one can be built step by step in the System Design playground, where you decide first and the guided solution then shows the reasoning.
What is inside this course
- Concept chapters with diagrams and runnable code
- Fifty end-to-end case studies
- The System Design playground
- Quizzes and flash cards
- A one-page cheat sheet and interview question bank
Who it is for
Developers and students preparing for system design interviews, and engineers who want to understand how large systems are built.
What you will be able to do
- Explain scalability, availability, consistency and latency with numbers, not slogans
- Choose between SQL and NoSQL, caches, queues and API styles and defend the trade-off
- Estimate load and storage with back-of-envelope maths
- Design a URL shortener, CDN, load balancer, key-value store, cache, auth system and a payments flow
- Spot single points of failure and plan failover and disaster recovery
Syllabus, start to finish
12 modules, 120 chapters.
1Foundations3
- The interview frameworkA system design question is deliberately vague, "Design TinyURL." Nobody expects you to know the answer.
- Back-of-envelope estimationYou cannot choose between "one database" and "a hundred shards" without knowing how much work the system must do.
- APIs, data model and choosing a databaseOnce you know what the system does and how big it is, define how the outside world talks to it (the API) and what it remembers (the data model).
2Core concepts9
- ScalabilityA system is scalable if it keeps working well when the load grows, and you can fix the growth by adding resources instead of rewriting everything.
- AvailabilityAvailability answers one question, when a user shows up, is the system working?
- ReliabilityA system is reliable if it does the right thing, every time, even when things go wrong.
- Single point of failure (SPOF)A single point of failure is any one component that, if it breaks, takes the whole system down.
- FailoverFailover is automatically switching to a backup when the main component fails, so users see little or no interruption.
- Fault toleranceA fault-tolerant system keeps working correctly while parts of it are failing, with no visible interruption.
- Latency, throughput and bandwidthThree words people mix up.
- Consistent hashingYou have data (or cache entries) spread over several servers.
- CAP theoremWhen data is copied on several machines, the copies can disagree for a moment.
3Networking8
- The OSI modelSending data between two computers is a huge job, radio waves, cables, addresses, lost packets, encryption, web pages.
- IP addressesAn IP address is the number that identifies a machine on a network, so packets know where to go.
- TCP vs UDPBoth move data between two programs over IP.
- ChecksumsA checksum is a small value calculated from a chunk of data.
- DNS (Domain Name System)People remember names (parottasalna.com), computers route by IP addresses (203.0.113.7).
- Proxy vs reverse proxyA proxy is a middleman that forwards requests on behalf of someone else.
- HTTP and HTTPSHTTP is the language browsers and apps use to ask servers for things.
- Load balancingA load balancer sits in front of many identical servers and decides which server handles each request.
4APIs8
- What is an API?An API (application programming interface) is a contract between two programs, "if you send me this, I will send you back that".
- REST vs GraphQLBoth are ways to build a web API.
- API gatewayWith many services behind your product, clients should not need to know about all of them.
- API designA well-designed API is easy to use correctly, hard to misuse, and survives years of change.
- WebSocketsNormal HTTP is a question and answer, the client asks, the server replies, the conversation ends.
- WebhooksA webhook is an HTTP request that a service sends to you when something happens, instead of you repeatedly asking "has it happened yet?".
- IdempotencyAn operation is idempotent if doing it many times has the same effect as doing it once.
- Rate limitingRate limiting controls how many requests a client may make in a time window.
5Databases10
- ACID transactionsA transaction groups several database operations into one all-or-nothing unit.
- SQL vs NoSQL- SQL (relational) databases store data in tables with a fixed structure and let you combine tables with joins.
- Database indexesAn index is a separate, sorted structure that lets the database jump straight to matching rows instead of reading the whole table.
- Database shardingSharding splits one big database into several smaller databases (shards), each holding a part of the data on its own machine.
- Data replicationReplication keeps copies of the same data on several machines, so one failure does not lose the data and more machines can answer reads.
- Database scalingA database becomes slow or full in different ways, and each problem has a different cure.
- Types of databasesThere is no single best database.
- Bloom filtersA Bloom filter is a tiny, fast structure that answers, "Have I definitely not seen this item?" or "I might have seen it." It uses very little memory and never says "no...
- Database architecturesBeyond choosing a database, you choose how copies of it are arranged across machines, zones and regions.
- Generating unique short IDsMany servers create IDs at the same moment, and no two items may get the same ID.
6Caching and CDN5
- Caching 101A cache is a small, fast storage that keeps copies of data you will probably need again, so you do not repeat the slow work of fetching or computing it.
- Caching strategies"Use a cache" is not a design.
- Cache eviction policiesA cache is smaller than the data it fronts.
- Distributed cachingOne cache server has limits, its memory, its network, and it is a single point of failure.
- Content Delivery Network (CDN)A CDN is a worldwide network of cache servers that keep copies of your files close to your users, so a visitor in Chennai gets the image from a server in Chennai inste...
7Asynchronous communication3
- Message queuesA message queue is a buffer between a producer and a consumer, the producer drops a message on the queue and moves on, a consumer picks it up and processes it later, a...
- Publish/subscribe (pub/sub)In pub/sub, a publisher sends a message to a topic without knowing who is listening, and every subscriber to that topic receives its own copy.
- Change data capture (CDC)Change data capture turns a database's changes into a stream of events.
8Distributed systems8
- HeartbeatsA heartbeat is a small message a node sends regularly to say "I am alive".
- Service discoveryIn a system of many services whose instances start, stop and move constantly, a client cannot have an address hard-coded.
- Consensus algorithmsConsensus is how several machines agree on one value (who is the leader, what the next log entry is, whether a transaction committed), even when some machines crash or...
- Distributed lockingA distributed lock makes sure that only one process across many machines does a particular thing at a time (run a cron job, update a shared record, be the leader).
- Gossip protocolIn a gossip protocol every node, at regular intervals, picks a few random peers and shares what it knows with them.
- Circuit breakerA circuit breaker watches calls to a dependency.
- Disaster recoveryDisaster recovery (DR) is the plan and tooling to get your system back after something big and unlikely destroys it, a data-centre fire, a cloud region outage, ransomw...
- Distributed tracingDistributed tracing follows one request through every service it touches, recording how long each step took, so you can see where the time went and where it failed.
9Architectural patterns5
- Client-server architectureIn client-server architecture one side, the client, asks for something and the other side, the server, provides it.
- Microservices architectureMicroservices break one big application into many small services, each owning one business capability, with its own data, deployed and scaled independently, talking to...
- Serverless architectureIn serverless, you write functions or small pieces of code, upload them, and the cloud provider runs them on demand, it provisions machines, scales to the number of re...
- Event-driven architectureIn an event-driven architecture (EDA), components communicate by publishing events ("an order was placed") that other components react to, instead of calling each othe...
- Peer-to-peer (P2P) architectureIn peer-to-peer, there is no central server.
10System design trade-offs11
- Top system design trade-offsThere is no perfect design, only designs that give up the right things.
- Vertical vs horizontal scalingWhen load grows you can make one machine stronger (vertical scaling, "scale up") or add more machines (horizontal scaling, "scale out").
- Concurrency vs parallelism- Concurrency is dealing with many things at once, structuring a program so several tasks can make progress by taking turns, even on one CPU core.
- Long polling vs WebSocketsBoth let a server tell a client about new data without the client constantly asking.
- Batch vs stream processing- Batch processing collects data over a period and processes it all at once on a schedule (nightly sales report).
- Stateful vs stateless architecture- A stateless server remembers nothing about a client between requests.
- Strong vs eventual consistencyWhen data is copied to several places, consistency describes what a reader sees right after a write.
- Read-through vs write-through cacheBoth patterns put the cache in the middle, between your application and the database, so the app talks to one place.
- Push vs pull architectureWhen data has to travel from a producer to a consumer, someone must start the transfer.
- REST vs RPCTwo ways to design how programs call each other over a network.
- Synchronous vs asynchronous communication- Synchronous, the caller sends a request and waits for the answer before doing anything else.
11Case studies10
- Design a URL shortener (TinyURL)
- Design autocomplete for a search engine
- Design a load balancer
- Design a content delivery network (CDN)
- Design a parking garage (object-oriented design)
- Design a vending machine (state machine)
- Design a distributed key-value store
- Design a distributed cache
- Design an authentication system
- Design UPI (Unified Payments Interface)
12More case studies40
- Design a Rate Limiter
- Design a News Feed
- Design a Chat App (WhatsApp)
- Design a Notification Service
- Design a Video Streaming Service (YouTube)
- Design a Ride-Hailing Service (Uber)
- Design a File Sync Service (Dropbox)
- Design a Web Crawler
- Design a Text Search Engine (Elasticsearch)
- Design a Distributed Message Queue (Kafka)
- Design a Distributed Job Scheduler
- Design a Unique ID Generator (Snowflake)
- Design a Ticket Booking System (BookMyShow)
- Design an E-commerce Cart and Checkout
- Design a Hotel Booking System (Airbnb)
- Design a Food Delivery App (Swiggy)
- Design a Metrics Monitoring and Alerting System
- Design a Log Aggregation System
- Design a Distributed File System (GFS/HDFS)
- Design an Object Storage Service (S3)
- Design a Social Graph (Friends and Suggestions)
- Design a Real-Time Leaderboard
- Design a Collaborative Document Editor (Google Docs)
- Design Pastebin
- Design a Digital Wallet
- Design an Ad Click Aggregation System
- Design a Feature Flag and Config Service
- Design a Nearby Places Search (Yelp)
- Design Trending Topics (Top-K)
- Design a Video Conferencing Service (Zoom)
- Design an Elevator System
- Design an ATM
- Design an Expense Sharing App (Splitwise)
- Design a Chess Game
- Design an LRU Cache
- Design a Logging Library
- Design a Meeting Room Booking System
- Design a Library Management System
- Design Snake and Ladder
- Design a Stock Exchange Order Matching Engine