Workstation topics · System design for builders
Coping with a rush: the Diwali sale
🏠The everyday picture
Before Diwali, the Sharma Textiles shop is packed. Mr Sharma does three things: he keeps the most-asked-for sarees at the counter instead of fetching them from the godown each time, he brings in extra counter staff with one person directing customers to whoever is free, and he takes delivery addresses on a slip to deal with after closing, instead of making the queue wait while each one is written up. Busy apps use the same three tricks.
📘What it really is
- Cache (keep popular things at the counter). A cache is a quick store of answers that are asked for again and again, such as the product list. The server answers from the cache instead of asking the database every time. The catch: the cache must be refreshed when the real data changes, or customers see old prices.
- More servers behind a load balancer (more counter staff). Several copies of the backend run at once, and a load balancer sends each request to one that's free. If one copy breaks, the others carry on.
- A job queue (the slips to deal with later). Slow jobs, such as sending an invoice email or a WhatsApp update, go into a queue (Lesson 2 of Data structures), and a separate worker sends them one by one. The customer gets "Order placed" straight away instead of waiting.
And one warning: a part that has only one copy is a single point of failure. If it stops, everything stops. Often it's the database, so it needs backups and a plan (Lesson 3).
📝A worked example
Last Diwali, the Sharma Textiles site slowed to a crawl at 8 pm. What the team found and changed:
| Problem | Change | Result |
|---|---|---|
| Every page view asked the database for the full catalogue | Cache the catalogue for 5 minutes | The database gets far fewer requests |
| One small server did everything | Two copies behind a load balancer | Roughly twice the capacity; if one fails, the other keeps the shop open, more slowly |
| "Place order" waited while the invoice email was sent | Put the email into a job queue | "Order placed" appears in under a second |
🖱️Try it
For your own app, or a cinema-ticket app, answer three questions in one line each:
- Which page will be asked for most often? Could it be cached? How old may it get before it must refresh?
- Which slow job could go into a queue instead of making the customer wait?
- Which part has only one copy, and what happens if it stops?
✅Quick check
After a price change, customers still see the old price for a few minutes. What's the likely cause?
Show the answer
A cache. It's still serving the saved copy. Refresh the cache whenever a price changes, or keep cached copies only for a short time.
Why does a job queue make "Place order" feel faster?
Show the answer
Because the slow part (sending emails or messages) happens afterwards, in the background, so the customer doesn't wait for it.
🧩Check yourself
Tap an answer to see why every option is right or wrong. There's no score and nothing is saved, so try as often as you like.