Capstone: system design projects for your resume

SeatJaldi now has 1 crore monthly users, 40 engineers in Baner and a ₹40 crore Series A. Meera Kulkarni asks Arjun Nair to present the design for the next stadium final sale to the board, in 5 minutes.

Arjun brings twelve slides of boxes. Meera stops him on the second. “Where is the peak? What breaks first?” Arjun knows every part, but has never put them in an order a listener can follow.

Afterwards, Zoya Mirza hands him a blank page with eight slots. “Fill them in this order and the pitch writes itself,” she says. “Which slot do most people skip?”

A good project is a small, familiar system designed end to end with numbers, such as a ticket app. You can explain every part of it, including what fails.

Keep one line in your head: requirements, numbers, boxes, failure review, then tell the story. It is lesson 34’s interview order, on paper.

• Requirements: what it must do, how well, and what you will not build.
• Numbers: the peak, storage and servers, with assumptions said.
• Boxes: the API, the data and the diagram, each tied to a number.
• Failure review: what breaks first, and one SLO.
• Story: a 5-minute pitch, a short spoken walk-through.

• A resume says “built a chat app with 10 lakh users”. The interviewer asks how that was measured, and the room goes quiet. Invented numbers fail one follow-up.
• A game shows “queue position 4,213” on launch day. The team sized for a peak and chose a waiting line to protect the servers.
• A friend’s side project breaks when two people use it at once. A tiny test with two callers finds that race.

Pick a house you can plan well, not a palace. Common beginner ideas: a ticket app, a tiffin subscription app, a bus-pass app, a URL shortener or a rate limiter.

Fill eight slots in order: requirements, numbers, API, data, diagram, scaling reads, protecting writes and work, then failure review and a pitch. It is Vasudha’s order: rooms, budget, plan, weak points, walk-through.

Most people skip the numbers, step 2, and then the failure review, step 8. Without a peak, nobody can say why a box is there or what breaks first.

Design for the real numbers and test a tiny version. A few small tests and a written review show the same skills without millions of users. Vasudha would test a scale model before building the real house.

• Two callers, one seat: send 100 hold requests for A12 at once. Expect one success and 99 conflicts.
• Same payment twice: send one idempotency key twice. Expect one charge and the same response.
• Stop the cache: watch database load jump, and check whether bookings still meet the SLO.

What just happened? Each curl sends one request; the & starts all 100 together. On a fresh seat, rate limiter off, the one-step hold gives 1 for 201 and 99 for 409. Two or more 201s mean double booking.

Sandeep Patil adds one more habit: write up every outage as a design lesson.

Bonus design review: read the postmortem of the October 2025 cloud outage that lessons 3 and 28 described. Find three ideas from this course in it: the hidden DNS dependency, retries and overload, and the blast radius.

Write each bullet as a number, a choice and a trade-off, then rehearse a five-minute pitch in the eight slots. Name the peak, what you chose over what and why, and what you tested.

• Designed seat booking for about 16,700 requests a second at peak, estimated from 5 lakh users x 20 requests in 10 minutes.
• Prevented double booking with a conditional update and 10-minute seat holds, trading a few rejected taps for correct seats.
• Made payments safe to retry with an idempotency key; sent one request twice and saw one charge.
• Set an SLO of 99.9% of bookings within 1 second over 28 days: about 40 minutes of error budget.

Say “estimated” for design numbers and “measured” for test results.

Then score your design, the way the family checks Vasudha’s plan:

• Requirements stated, including out of scope.
• The estimate shown, with its assumptions.
• Single points of failure named and fixed.
• A consistency model chosen per feature.
• One SLO, with its error budget.
• One change you would make at 10 times the load.

Try it yourself

1. 1

   Pick a brief

   SeatJaldi’s stadium final sale, a Pune tiffin app or a city bus-pass app, each with its starting numbers.

2. 2

   Fill the worksheet

   Write all eight steps on paper, in order, with your own numbers.

3. 3

   Run one test

   Start with two callers, one seat, rate limiter off, and write down the counts.

4. 4

   Write four bullets

   Number, choice, trade-off, result.

5. 5

   Pitch it

   Time five minutes, then take two follow-up questions from a friend.

6. 6

   Check your answer

   You pass if all six self-review lines are ticked and every bullet holds a number you can explain. The test result is measured, and the pitch fits 5 minutes without notes.

Back in the board room, Arjun pitches again. The slot he skipped, the numbers, now comes second: a peak of 16,700 a second, with a number behind every box. Meera takes the one-page version to the board.

Then Sandeep reads the postmortem of the 22-minute outage aloud. “The retry storm is on page one. Our design review never asked about a slow gateway.” Arjun marks the lessons that would have caught it: retries, timeouts, the circuit breaker. That was the monsoon question, never asked.

Arjun sends the blank worksheet to Shreya, the fresher from Nagpur, for her next practice round. He can tell the whole journey now, from one ₹1,200 server to 1 crore users. You can now design and defend a system: take it from one server to millions, explain every part, and say it out loud, so go and practise it on a real question.

One last game, across the whole module.