System Design line, station 1 of 8
How the Web Works
Follow one request from a phone to a server and back, design APIs that survive real networks, and put numbers on speed, load and reliability.
- 6lessons
- 3 hto read and do
- Beginnerlevel
- 6podcast episodes
- 9checked exercises
- 2simulators
Tools you'll use in this course
The lessons open these with a template ready. They work for your own job too, no course needed.
About this course
This is the first course of Kolom's System Design track and the place to start if you are new to how software systems work. You follow a single tap in an app all the way to a server and back: DNS, TCP, TLS, HTTP and what the server does with the request. Then you learn the small set of networking ideas every designer needs, and how to design APIs that other teams and apps can rely on.
The second half is about numbers. You learn to turn "how many users?" into requests per second and gigabytes per year, to read p95 and p99 instead of averages, and to agree reliability targets with SLOs and error budgets. Every lesson uses Mangrove Market, a fictional grocery chain with stores, a delivery app, riders and partner shops, so the examples build on each other.
Each lesson has diagrams, a worked example, real code you can run, checkpoints, practice tasks (many auto-checked in your browser), flashcards and a podcast episode. The course ends with a capstone design brief and a final exam for a free certificate.
What you will be able to do
- Turn a vague feature request into functional and non-functional requirements with real numbers
- Explain every step of a web request, from DNS to the response, and measure where the time goes
- Spot common network and server mistakes, such as a database that is open to the internet
- Design REST endpoints with honest status codes, cursor pagination and retries that are safe
- Estimate requests per second and storage for a feature in a few minutes
- Set latency and availability targets with percentiles, SLOs and error budgets
Syllabus
6 stops, about 3 h in total. Each stop fills in when you complete the lesson.
What system design really is
Welcome to Kolom. This is the first lesson of the System Design track, and you need no experience of system design to start it. System design is planning how the parts of a software system fit together so it keeps working at the numbers you expect: the users, the busy hours, the failures. This lesson gives you the words and the thinking loop that every later lesson uses.
Requirements and trade-offsNon-functional requirementsDesign thinking loop
What happens when you open an app or website
Between a tap on the screen and the data appearing, your request makes several trips across the network. This lesson follows one request step by step, so you can see where the time goes and which steps you can remove.
HTTP and the request journeyDNS and TLSLatency debugging
Networking you actually need
You do not need to be a network engineer to design systems, but you need a small set of ideas: addresses and ports, TCP and UDP, the HTTP versions, certificates, and how a safe network is laid out. With these you can look at a server setup and spot the door that was left open.
Networking and portsTCP and UDPServer hardening
APIs done right
An API is a promise between the app team and the server team. A good one is easy to use correctly and hard to use wrongly: clear resources, honest status codes, one error format, pagination that does not lose rows, and POST requests that are safe to retry.
API designIdempotencyPagination
Speed numbers and back-of-the-envelope math
Five minutes of rough math often tells you whether a design needs one server or fifty. This lesson gives you the few numbers to remember and a method for turning "how many users?" into requests per second and gigabytes per year.
Capacity estimationLatency and throughputStorage sizing
Measuring speed and reliability: p99, SLOs and nines
"Is the app fast?" and "Is it reliable?" only have useful answers when you measure them the right way. This lesson shows why averages hide the pain, how percentiles show it, and how SLOs and error budgets turn reliability into a number the business and engineers can agree on.
Percentiles and latencySLOs and availabilityError budgets
Capstone: Design brief: delivery tracking in the Partner app
A realistic project with a rubric and a model answer.
Final exam and certificate
10 questions drawn at random, 70% to pass.
Capstone project
Design brief: delivery tracking in the Partner app
Mangrove Market's Partner app lets about 1,800 independent corner shops order stock wholesale from its 4 distribution centres. Shop owners phone the DCs all day asking "where is my delivery?". Imran wants a feature where a shop sees its open orders, each order's status (packed, on the truck, delivered) and an expected arrival time, and confirms receipt with a count of cartons, which updates the shop's invoice. Many shops run on patchy mobile data, and order volume triples in the week before a festival. Write the design brief Imran will take to the design review: requirements with numbers, the API, a capacity estimate, the network budget for the main screen, and the SLOs. Use the lessons' templates and your own reasoned assumptions where a number is missing.
You will hand in
- A requirements sheet: 3 to 5 FRs, at least 6 NFRs with numbers, an out-of-scope list and open questions
- An API contract for 3 to 5 endpoints: methods, paths, status codes, one error shape, cursor pagination and a receipt confirmation that is safe to retry
- A back-of-the-envelope estimate of peak requests per second and yearly storage, with every assumption listed
- A network budget for the open-orders screen on a 200 ms mobile link: calls, round trips and total time
- An SLO document for the two most important endpoints, with an error budget policy
Check what you know
Already know some of this? Answer 6 quick questions, one from each lesson, and we will mark the lessons you can skim. It takes about 3 minutes and nothing is graded.
Questions
How long does the course take?
About 3 hours for the six lessons, including the checkpoints and practice tasks. The podcast episodes add about 80 minutes if you listen to all of them. Allow 2 to 6 hours more for the capstone design brief.
Do I need to know anything before I start?
No system design experience is needed. It helps to have used apps and to have seen a little code. The Build it sections use TypeScript, SQL and a terminal, but every lesson explains what each step does, and product managers can follow the reasoning without running anything.
What do I need to install?
Nothing to read the lessons or do the practice exercises: SQL runs in a real PostgreSQL database inside your browser, and JavaScript runs with tests there too. To do the Build it sections on your own machine you need a recent Node.js LTS, PostgreSQL 16 or later, and the curl and dig tools. The networking lesson's Build it also needs a Linux server you control, such as a small cloud machine.
Is the certificate free?
Yes. Pass the final exam and you get a free certificate with a link that anyone, such as an employer, can use to check it.
How does the final exam work?
Each attempt has 15 questions picked at random from a larger bank that covers all six lessons, and you need 70% to pass. The questions are new scenarios, not the lesson quizzes. If you do not pass, you can try again after 24 hours.
Is it really free?
Yes. Every lesson, podcast episode, exercise, quiz, final exam and certificate is free. The labs and their templates for real work are free too. Plus and Premium add every lab challenge, weekly extras and a mentor on top, and they never lock the tools or the courses.