High-volume systems

What “high volume” means here

In August 2026, UPIUnified Payments Interface. NPCI's real-time system for paying from a bank account with a UPI ID, QR code or phone number, through apps on a phone. processed 24.51 billion transactions^{1Business Standard. UPI sets new record at 24.51 bn transactions in Aug, value at ₹29.82 trn. As of 31 August 2026.}, about 791 million a day^{1Business Standard. UPI sets new record at 24.51 bn transactions in Aug, value at ₹29.82 trn. As of 31 August 2026.}, and IMPSImmediate Payment Service. NPCI's instant, round-the-clock interbank transfer service, used with an account number and IFSC or with a mobile number. another 360 million transactions^{1Business Standard. UPI sets new record at 24.51 bn transactions in Aug, value at ₹29.82 trn. As of 31 August 2026.}. Every one of those payments touches at least two banks’ systems, and demand is not spread evenly. It climbs on predictable days:

• Salary days, at the start of the month, when credits arrive and spending follows.
• Loan instalment and bill dates, in the first week, when mandates debit millions of accounts.
• Month end and financial-year end, when businesses settle and reporting runs.
• Festive sales, when card and UPI payments to merchants spike for hours.
• Deadline days, such as tax due dates or popular share offers, when many people pay in the same window.

The consequence of getting this wrong is public and regulatory, not just technical. RBI said the bank's core banking system and online channels had suffered frequent and significant outages over the previous two years, and that rapid growth in digital transactions was adding load on its IT systems.^{4Inc42. RBI bars Kotak Mahindra Bank from onboarding new customers via online, mobile banking channels. As of 24 April 2024.} On 24 April 2024 RBI directed Kotak Mahindra Bank to stop onboarding new customers through online and mobile channels and to stop issuing new credit cards, citing concerns from its IT examinations of the bank for 2022 and 2023.^{5All India Radio News (Prasar Bharati). RBI directs Kotak Mahindra Bank to cease issue of fresh credit cards, bars onboarding of new online customers. As of 24 April 2024.}

Shielding the core

The core banking system is usually the hardest component to scale, so high-volume design is largely about protecting it. Requests pass through layers that each absorb part of the load before anything reaches the ledger.

• Caching serves reads, such as a balance shown on an app’s home screen, without asking the core each time.
• Queues buffer writes, so a peak becomes a slightly longer line rather than a failure.
• Back-pressure slows or rejects new work when the systems behind are saturated, instead of letting everything time out together.
• Rate limits protect shared capacity from any one channel, partner or runaway client.

Idempotency and safe retries

At high volume, time-outs are not rare events but a steady stream. A client that times out will retry, and a retry must never move money twice. Each payment therefore carries a unique reference from its sender, and every system records references it has already processed. A repeated request returns the original result.

Retries themselves need discipline: wait longer between each attempt, add a little randomness so thousands of clients do not retry in step, and stop after a limit. Payments that end up stuck must still be resolved within regulatory limits. If a UPI transfer debits the payer but does not credit the beneficiary, the beneficiary bank must reverse it by T+1 day; after that, ₹100 a day is payable.^{2Reserve Bank of India. Harmonisation of Turn Around Time (TAT) and customer compensation for failed transactions using authorised Payment Systems (RBI/2019-20/67). As of 20 September 2019.}

Circuit breakers, bulkheads and graceful degradation

A circuit breaker stops calling a failing dependency for a short time, returning a fast failure instead of waiting on time-outs, then tests it again. A bulkhead gives each channel or function its own pool of threads and connections, so a problem in one cannot exhaust capacity for all. Graceful degradation keeps the most important functions working when something fails. Payments may continue while statements and analytics pause. The app may show a balance marked “as of” a few minutes ago, rather than an error.

Stand-in processing is the payment-specific form. When the core is unavailable or busy with its batch cycle, a stand-in layer approves low-risk transactions against a shadow balance within limits, and replays them to the core afterwards. It keeps payments flowing, at the cost of reconciliation work.

Asynchronous processing and the outbox

Work that does not need to finish before the customer gets an answer, such as notifications, loyalty points or analytics, is done asynchronously. The service records the change and an event in one database transaction, the outbox, and a separate process publishes the event. That keeps the customer path short and the event reliable. See event-driven architecture.

Capacity planning, load testing and warm capacity

Capacity is planned for the peak, not the average, with headroom on top. Load tests replay realistic peak traffic, including the mix of payment types and the slow dependencies, not just a simple script. Autoscaling helps for stateless services, but new capacity takes time to start and warm up. Banks therefore scale up before known peaks rather than waiting for load to rise. Databases and cores usually cannot autoscale at all, which is why the shielding layers matter.

Batch windows

Not all volume is real time. Mandate collections, salary files and statement runs arrive as large batches, often at the same times each month. Batch jobs are scheduled so they do not collide with real-time peaks, split into pieces that can run in parallel, and checkpointed so a failure resumes rather than restarts.

Latency budgets for fraud scoring

Real-time fraud scoring sits inside the payment path, so it gets a fixed slice of the time available. An illustrative budget might give the fraud engine a few tens of milliseconds. If it cannot answer in time, the payment proceeds or stops by a pre-agreed rule, rather than waiting. Any such figure here is illustrative; each bank sets its own from its end-to-end limits.

Measuring success: SLOs and resilience drills

The measure that matters is the share of payments that succeed, and how fast, broken down by channel, partner and type. Service level objectives turn that into targets, and error budgets decide when reliability work takes priority. Resilience is proven by drills, not by design documents. DR drills for critical information systems must be held at least every six months, and major issues found in a drill must be fixed and tested again before the next cycle.^{3Reserve Bank of India. Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023 (full text). As of 7 November 2023.} A DR test must switch over to the DR or alternate site and run it as the primary site long enough to cover at least a full working day, from beginning of day to end of day.^{3Reserve Bank of India. Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023 (full text). As of 7 November 2023.}

Questions for a design review

• What is the expected peak for this system, on which day, and what headroom does it have above that?
• Which layer absorbs the peak before it reaches the core?
• How does every client retry, and does every retry reuse its reference?
• What does this system do when a dependency is slow: wait, fail fast or degrade?
• When was it last load-tested at peak volume, with realistic traffic?