Big data at Indian scale: UPI, IRCTC, live cricket and sale days

10:00 am in India

Big data at Indian scale

Words you’ll meet in this lesson

Published figures used in this lesson

Sources are listed at the end of the Real-world use section. Internal designs of these systems are not fully public: the architecture shown here is the standard pattern for each problem, not a confirmed blueprint.

India-scale systems at three levels

Payments, booking rushes, live streaming and sale days

Which big data ideas carry each system

From a headline number to a design

1. Start from a published number

   per_month = 24.07e9
   per_day = per_month / 30
   print(f"{per_day / 1e7:.1f} crore a day")
   print(f"{per_day / 86_400:,.0f} per second on average")

   80.2 crore a day 9,286 per second on average
   Monthly or daily totals sound huge, but systems are designed in requests per second. 24 billion a month is about 9,300 per second on average.

2. Estimate the peak

   avg_tps = 9_286
   for ratio in [2, 3, 5]:
       print(f"peak x{ratio}: {avg_tps * ratio:,} TPS")

   peak x2: 18,572 TPS peak x3: 27,858 TPS peak x5: 46,430 TPS
   Traffic is not flat: evenings, salary days, festivals and sale launches are much busier. Designers use a peak-to-average ratio from history and add headroom on top.

3. Find the critical path

   For UPI: app → switch → payer bank → payee bank → confirmations. For IRCTC: search → availability → seat allocation → payment. Only these steps must succeed in real time.

   Everything else (rewards, notifications, analytics) can be asynchronous through queues, so it never slows the critical path.

4. Spread and protect the load

   Partition data and traffic (by account, train, region), replicate for failures, cache what is read often, and put a queue or rate limiter in front of anything that can be overwhelmed.

   These are the Module 3 ideas: scale out, shard, replicate, choose consistency per data type.

5. Size the data platform

   tps, bytes_per_event = 9_286, 1_000
   gb_per_day = tps * 86_400 * bytes_per_event / 1e9
   print(f"{gb_per_day:,.0f} GB of events a day, {gb_per_day * 365 / 1e3:,.0f} TB a year")

   802 GB of events a day, 293 TB a year
   Each transaction creates events for fraud checks, dashboards and audit. Even small events add up to terabytes a year, before replication and logs.

6. Rehearse the big day

   Load-test at the expected peak plus margin, pre-scale capacity before the event, prepare switches to turn off non-essential features, and watch live dashboards during the event.

   Known peaks (Tatkal, a final, a sale) are planned like launches, with game days and runbooks, not left to chance.

One UPI payment: what Riya sees, and what happens behind

Step through the six frames. Left: Riya paying a tiffin shop. Right: a simplified view of the request moving through the UPI network.

Real-time scenarios: rush, retry and live stream

Three live scenarios: the Tatkal waiting room (real numbers from the program below), a payment retry at peak that must not debit twice, and an advanced look at serving crores of live cricket viewers.

Tatkal at 10 am: a waiting room protects the booking system

These figures come from the program in “Run it on your PC” below: 30,000 users arrive in one minute, but the booking system admits only 250 per second. Watch the queue absorb the spike.

A retry at peak must not debit twice

At peak, slow links and timeouts are normal. Watch how a unique transaction ID makes a retry safe, which is the core reason payment systems can scale out without losing money.

Crores join the same match in minutes

Live streaming is the opposite of payments: everyone reads the same data. The hard parts are bandwidth, sudden joins and keeping quality up. Watch the standard design at work.

Four systems, four lessons

Sources for the figures

• UPI monthly volumes (August and September 2026): NPCI data as reported by StartupTalky, September 2026 and StartupTalky, August 2026.
• 5.9 crore concurrent viewers, 2023 World Cup final: exchange4media, November 2023.
• IRCTC peaks (37,410 tickets per minute; 18.4 lakh tickets in a day) and online share: Indian Railways figures as reported by IANS and Free Press Journal (2025–26); planned upgrade to over 1 lakh bookings a minute reported by Outlook Money, August 2026.
• Figures are as published; check the latest NPCI and IRCTC releases before quoting them.

Turn headline numbers into engineering numbers

A few published figures are converted into average transactions per second and a design peak. Then try the challenges: peak ratios, event volumes, waiting-room maths, CDN bandwidth and hot keys.

figures = {                          # (count, seconds it covers)
    "UPI, Sep 2026 (month)": (24.07e9, 30 * 86_400),
    "IRCTC record day":      (18.4e5, 86_400),
    "IRCTC peak minute":     (37_410, 60),
}
PEAK_RATIO = 3                       # assumption for daily or monthly averages

for name, (count, seconds) in figures.items():
    tps = count / seconds
    print(f"{name:22}: {tps:8,.0f} per second")
print(f"UPI design peak at x{PEAK_RATIO}: {24.07e9 / (30 * 86_400) * PEAK_RATIO:,.0f} TPS")

• tps = count / secondsEvery design starts here: divide a total by the seconds it covers.
• PEAK_RATIO = 3 # assumption for daily or monthly averagesAverages hide peaks. A peak minute is already a peak, so the ratio is applied only to long averages.

Run it on your PC: India-scale load and a Tatkal waiting room

This program converts published UPI, IRCTC and live-streaming figures into per-second load and bandwidth, then simulates a virtual waiting room: 30,000 users arrive in one minute and are admitted at 250 per second. Change the arrival count or admit rate and run it again. Save it as indian_scale.py.

"""India-scale numbers turned into per-second rates, and a Tatkal-style
virtual waiting room that admits users at a safe rate."""
import random

published = {
    # figure, unit, source (see the lesson's Sources list)
    "UPI, September 2026": (24.07e9, "transactions in the month"),
    "IRCTC, peak minute (16 Aug 2025)": (37_410, "tickets in one minute"),
    "Live cricket, 2023 World Cup final": (5.9e7, "concurrent viewers"),
}

upi_per_s = 24.07e9 / (30 * 86_400)
irctc_per_s = 37_410 / 60
viewers = 5.9e7
bitrate_mbps = 2.5                       # assumption: an average mobile stream
print(f"UPI average           : {upi_per_s:,.0f} transactions per second")
print(f"IRCTC peak            : {irctc_per_s:,.0f} tickets per second")
print(f"Live final, bandwidth : {viewers * bitrate_mbps / 1e6:,.0f} Tbps if every viewer streams {bitrate_mbps} Mbps")

# ---- a virtual waiting room for a 10:00 am rush
random.seed(3)
arrivals = sorted(random.uniform(0, 60) for _ in range(30_000))   # 30,000 users in the first minute
ADMIT_PER_SECOND = 250                                            # what the booking system can safely take
admitted_at = []
next_slot = 0.0
for t in arrivals:
    start = max(t, next_slot)
    admitted_at.append(start)
    next_slot = start + 1 / ADMIT_PER_SECOND
waits = [a - t for a, t in zip(admitted_at, arrivals)]
print(f"\nWaiting room: {len(arrivals):,} users arrive in 60 s, admitted at {ADMIT_PER_SECOND}/s")
print(f"  last user admitted after {admitted_at[-1]:.0f} s")
print(f"  median wait {sorted(waits)[len(waits) // 2]:.0f} s, worst wait {max(waits):.0f} s")
print("  the booking servers never see more than 250 users per second")

# In a terminal:  python indian_scale.py

Admitting a rush, one user at a time

Five users arrive almost together; the system admits one every 2 seconds. Watch each user’s admit time and wait being calculated.

Worked examples: real problems, solved and traced in memory

Four estimation and design calculations from India-scale systems. Each runs live and is traced.

18.4 lakh per day · 37,410 per minute

average 21/s, peak 624/s, ratio 29x

9,300 TPS, 4× peak, 30% headroom, 800 TPS/server, 2 sites

design load 48,360 TPS -> 61 servers
survive one site down -> 61 per site, 122 in total

(txn_id, amount) pairs

3 payments, 3 retries, Rs 1120 not double-debited

6 crore viewers, bitrate mix, 60 Tbps per CDN, 25% spare

avg 1.96 Mbps, peak 118 Tbps, CDNs needed 3
one CDN down: 120 Tbps, covers 100% at full quality

Check yourself

Quick revision

Interview and viva questions

Practice problems

Estimation and design problems based on Indian systems. The last two are business tasks.

50 crore/day

5787

print(round(50e7 / 86_400))

37,410/min

624

print(round(37_410 / 60))

5.9 crore

59,000,000

print(f"{int(5.9e7):,}")

12,000, 4×, 25%

60000

print(int(12_000 * 4 * 1.25))

45,000, 60 s, 300/s

150.0 seconds

print(max(60, 45_000 / 300), "seconds")

as given

23.1 TB/day

print(round(9_300 * 86_400 * 8 * 1.2e3 * 3 / 1e12, 1), "TB/day")

list of IDs

['t1', 't2', 't3']

ids = ["t1", "t2", "t1", "t3", "t2"]
print(list(dict.fromkeys(ids)))

1.8 lakh/min, +35%, +30%

5265

print(round(1.8e5 * 1.35 * 1.3 / 60))

Rs 29.37 lakh crore/month

Rs 68 crore per minute

per_min = 29.37e12 / (30 * 24 * 60)
print(f"Rs {per_min / 1e7:,.0f} crore per minute")

Real-world scenario questions (asked in company interviews)

Questions about India-scale systems from interviews and real projects. Decide your answer first, then open the model answer.