An Indian UPI payments app peaked at 22,000 payments per second for one minute on last year's biggest festival evening, against a normal daily peak of about 3,500. Transaction volume has grown roughly 35 percent year on year, and this year a large e-commerce sale overlaps the festival. In March a viral cashback campaign took traffic from 4,000 to 15,000 per second in under three minutes with no warning, and the HPA-driven services fell over before new nodes were ready.
The interviewer asks“Walk me through how you'd build the capacity plan for the festival season, including the spikes nobody puts on the calendar. I want to see the actual numbers, not just 'we'll autoscale'.”
I forecast the one-minute peak from history, growth and the overlapping sale, then turn it into a design target with explicit headroom and an AZ-failure margin. Load tests give me the knee of every component, and the plan is simply forecast divided by safe per-unit throughput, pre-scaled on a schedule and backed by reserved capacity and raised quotas. The real ceiling is usually the sponsor banks and issuer banks, so those limits are negotiated in advance and admission control is set below them. For spikes nobody predicts, standing headroom absorbs the first minutes, and a pre-agreed degradation ladder plus load shedding protects payments while autoscaling catches up.
A free account unlocks the rest of it, and saves your progress across every track.
sar Collect and replay system activity historympstat Per-CPU utilisation: find the hot corepidstat Per-process CPU, memory, disk and context switches over timesysctl Read and tune kernel parameters at runtimeulimit Show and set per-process resource limitsnumactl Control NUMA CPU and memory placementstrace Trace the system calls a process makesltrace Trace the library calls a program makes