How to scale an app to millions of users, step by step

SeatJaldi’s national final sale runs clean, with no outage. The ₹40 crore Series A is in, yet Meera Kulkarni is more worried than relieved.

Investors asked her: “What did you buy, and when should you have bought it?” The bill is ₹18 lakh a month for 1 crore users. She cannot explain one rupee of it.

Arjun Nair joined at 100 club members. He can name every part, but not the number that made the team buy it. Sandeep Patil shrugs: every graph is green.

Zoya Mirza draws eight boxes on the whiteboard, one per stage. “Every one of these was bought on a day a number went red,” she says. “But one purchase on this journey came before any number asked for it. What?”

You scale in steps, adding one part at a time, and each step is triggered by a number that has gone red. A number goes red when it crosses what the system can take.

• Find the number that has gone red.
• Add the smallest part that moves that exact number.
• Measure again, and wait for the next red number.

Keep one line in your head: add each part only when a number says you need it. Most often, that number is the peak from lesson 7.

• You have seen this: a ticket site opens fine at 10 am but shows a waiting page at noon on sale day. It was sized for the noon peak, and the waiting page protects the servers.
• A food app shows menu photos at once, but “Place order” is slower. Photos come from a nearby edge server; the order must reach the database.
• Asked to scale an app, a student says “Kafka and shards” without asking about today’s users. The interviewer wanted the number behind each step.

Eight steps, each with its own trigger. This is the order to learn, not the order SeatJaldi bought them. The bigger box came before the separate database, and shards and regions before the queue.

So what came early? Not one of the eight boxes. It hid inside the database: in lesson 15, Arjun added six extra indexes at once, to be safe. Four served no screen and slowed writes at noon, so he dropped those four.

Read the symptom, find the number behind it, then pick the smallest part that moves that number. Vaishali knows this: a second counter will not help if the batter shop behind it is slow.

What just happened? Each symptom pointed at one number, and only one step moved it. The wrong options were real parts, but each fixes a different number.

Each step has a monthly cost and a cost to undo, so the hard-to-undo steps come last. Vaishali can sell back a bigger tawa, but not ten cities.

• Cache, lesson 11’s sum: 95% hits, a 0.5 ms hit and a 5 ms database read. A miss checks the cache first: 0.95 × 0.5 + 0.05 × (0.5 + 5) = 0.75 ms, against 5 ms uncached.
• Users grew 1 lakh times; the bill grew 18,00,000 / 1,200 = 1,500 times.
• Resharding with hash mod N, four shards to five: a key stays only if key mod 4 equals key mod 5. Of keys 1 to 20, only 1, 2, 3 and 20 do, so 80% move.

At every stage, ask lesson 1’s three questions again. Single point of failure? 10 times the load, 1,67,000 a second? A slow part it needs?

Try it yourself

1. 1

   Redraw from memory

   Draw the seven final boxes without looking.

2. 2

   Tag each box

   Write the stage it arrived in, its trigger number, and any rupee cost you remember.

3. 3

   Pick one to skip

   Circle one box you would not build for 100 users, and write why.

4. 4

   Check your answer

   You are right if every box has a stage and a trigger, the order matches the stepper, and you named one box to skip.

Back at the whiteboard, Zoya taps the database box. “The indexes were the same mistake as buying a stage early, only smaller.” Arjun grins. “Wait, so the order was never fashion. It was eight red numbers.”

Meera reads the growth map, and the bill makes sense: ₹12 a member at the start, 18 paise a user now. Like Vaishali’s ten cities, shards and regions waited until a number demanded them. Her plan for investors: add the next part when the next number goes red.

Arjun will run SeatJaldi’s fresher interviews. Can he explain all this in 45 minutes, and can a fresher?