System Design Fundamentals

System design is the work of deciding how the parts of a software system fit together. The goal is a system that stays fast, correct, and available as it grows. The parts are things like web servers, databases, caches, load balancers, and message queues. System design fundamentals are the small set of building blocks and ideas that every large system is made from. This course teaches them one at a time, in the order you need them. Each chapter takes one building block. It explains what problem the block solves, what new problem it creates, and when you need it. You start with the qualities every system is judged by: scalability, availability, latency, and fault tolerance. Then you learn to estimate load with back-of-the-envelope math. That lets you say how many requests per second a design must handle before you draw a single box. From there the course follows the path a request takes. Network essentials cover HTTP, TCP against UDP, and what happens when you type a URL into a browser. DNS turns a name into an address. A proxy sits between a client and a server. A load balancer spreads traffic across many servers. An API gateway gives clients one entry point. A rate limiter protects a service from too many requests at once. Next come the parts that make a system fast and let it grow. Caching keeps a copy of frequently read data close to the reader. A content delivery network (CDN) serves files from servers near the user. Data partitioning splits a large dataset across many machines. Redundancy and replication keep extra copies of data, so one failed machine does not lose it. The real-time chapter compares long-polling, WebSockets, and server-sent events, the three ways a server pushes updates to a browser. The data chapters explain SQL and NoSQL databases and when each fits. They cover ACID against BASE, normalization, database federation, and in-memory against on-disk storage. You learn how an index works, from B-trees to LSM trees, and how indexes behave when the data is spread across machines. Bloom filters show how to answer "have I seen this before?" with very little memory. The CAP and PACELC theorems explain what a system can and cannot promise when the network breaks. The distributed systems chapters cover the patterns that keep many machines working as one: quorum, leader and follower, heartbeat, and checksum. Distributed messaging explains queues, Kafka, common messaging patterns, and the differences between RabbitMQ, Kafka, and ActiveMQ. Distributed file systems show how a single file is stored across many machines. The security chapter covers authentication, authorization, OAuth against JWT, encryption, and DDoS attacks. Who this course is for. It is for software engineers and students who are new to distributed systems. It is for backend developers who use these parts at work but have never had them explained from the start. It is for anyone preparing for a first system design interview who needs the vocabulary before the practice. You need basic programming knowledge and nothing else. Every term is defined in plain words the first time it appears. How the course works. The lessons are text-based, with a diagram wherever a picture explains more than a paragraph. Every topic chapter ends with a flashcards review and an adaptive assessment, so you check what you remember before moving on. The course closes with a final quiz drawn from a question bank that covers every chapter. It takes about 20 hours in total, and it is self-paced, so you can spread that over a few weeks or a few months. What comes next. Grokking the System Design Interview is the step after this course. You are ready for it when you can explain what a load balancer, a cache, a replica, and a message queue each do. That course builds directly on this one with a step-by-step method for the interview and real design problems worked end to end. Take this course first if those parts are still new to you. This course was formerly called Grokking System Design Fundamentals. The name changed; the content and your progress did not.