Abhishek Joshi leads Cloud Architecture & Permitter Security where he is responsible for infrastructure reliability, resilience, and security posture across mission-critical payment systems. He works at the intersection of engineering excellence and business strategy, translating complex infrastructure challenges into scalable, compliant, and future-ready solutions. His work ensures merchants can process payments with uninterrupted uptime, ironclad security, and full regulatory compliance, so businesses can focus on growth without worrying about the infrastructure behind every transaction.
A technical breakdown of the edge absorption, stateless scale-out, and admission control that kept every merchant transaction alive.
The Truth: You do not get to choose your traffic
Most infrastructure is designed around a forecast. You estimate demand, provision for it, add a margin, and move on. That is a reasonable way to build almost anything, but it is a terrible way to think about payment gateway scalability. High-throughput payment processing is not a forecasting problem; it is a survival problem.
A payments platform is a public endpoint. It is reachable, by design, by anyone on the internet, at any hour, from any country. That is not a flaw in the architecture, it is the product. But it means the volume arriving at your edge in the next sixty seconds is not something you control, not something you were told about, and not always something that wants to buy anything.
Every other system gets to plan for its load. Payment infrastructure has to survive load it was never told was coming.
This is the discipline that matters, and it is rarely the one that gets written about. Handling a peak you scheduled is capacity planning. Handling a peak you did not schedule is engineering.
What exactly happened
We recorded a sustained peak of 48,000 transactions per second against our platform for approximately two hours. Measured against our average traffic of roughly 17.5 TPS, the surge ran at close to 2,700 times normal traffic. It was not planned, it was not announced, and it did not resemble our normal traffic curve in shape or in origin.
No merchant lost a transaction. That is the only success criterion that matters, and it is worth being precise about why it held.
Figure: The surge, by the numbers, peak TPS, edge absorption, and scale-out.
The architecture that absorbed it
1. Edge computing for payments: the edge absorbs first, so the core never sees the storm
The single most important decision in our architecture is that the majority of unexpected volume never reaches our payment core at all. It is terminated, evaluated, and absorbed at the edge, geographically distributed, close to wherever the traffic originates.
Edge computing is usually sold as a latency story. It is at least as much a resilience story. An edge network has an enormous, globally distributed capacity envelope that no single origin region can match, so it can absorb a surge that would flatten a centralised stack, and it does so thousands of kilometres away from the systems that actually move money.
Our authorisation core is deliberately small, deliberately boring, and deliberately protected. It handles transactions. It does not handle weather.
Figure: How PayGlocal absorbs a traffic surge, internet through global edge, elastic API layer, to payment core.
Of the 48,000 TPS peak, our edge layer, WAF filtering plus cache, absorbed roughly 46,818 TPS through mitigation and a further 1,512 TPS served straight from cache. Only about 57 TPS ever reached origin, beyond the edge. Put differently: 99.88% of the surge was absorbed at the global edge before it touched origin, and for every request that reached origin, roughly 850 were stopped or served at the edge.
This design protects what matters most: international card payment processing, where the buyer is at checkout holding a card. The edge has to fail gracefully before that transaction reaches a congested origin.
2. Stateless core, elastic scaling of the API layer
Everything that can be made stateless is made stateless. Our API and authorisation layers hold no session, no local state, no sticky routing. Any node can serve any request from any merchant in any country. This is what turns scaling from a project into a parameter, and it is the foundation of elastic scaling for payment infrastructure.
When the surge began, our cloud infrastructure scaled out horizontally, automatically, without a human in the loop. This matters more than it sounds. Unexpected load does not arrive during office hours in your timezone; it arrives at 3am, and any architecture whose response to a surge requires someone to wake up and make a decision has already failed.
During the surge, our elastic API layer scaled from a steady baseline of 3 nodes to a peak of 22 nodes, roughly 7.4x, entirely through automated scaling triggered by CPU and memory utilisation, with no manual intervention. Based on 5-minute interval monitoring, the climb from baseline to peak took approximately 60 to 75 minutes, holding at an elevated level with some oscillation before winding back down to baseline within about two hours of the surge starting.
Figure: Elastic API layer node count during the surge, 3 nodes to 22, over roughly two hours.
3. Admission control: protect the paying transaction
Systems under extreme load rarely fail because they are too slow. They fail because they accept more work than they can finish, and then exhaust themselves on work that has already timed out.
So we do not try to serve everything. We enforce admission control at the edge, and we make a hard, unsentimental choice: if the platform cannot complete a request within its budget, that request is rejected immediately and cleanly rather than accepted and failed slowly. Capacity is reserved for transactions that represent a real buyer, with a real card, completing a real purchase.
A payment that fails fast is recoverable. A payment that hangs is not.
4. Isolation: one tenant's storm is never another tenant's outage
Our merchants share infrastructure, and they must never share each other's bad days. Rate limits, quotas, and bulkheads are applied per merchant, so an anomalous surge in one corner of the platform cannot consume the capacity that another merchant's checkout depends on.
5. Graceful degradation, in a defined order
Under sustained pressure, we shed load in a pre-agreed sequence: reporting queries before webhooks, webhooks before captures, captures before authorisations. The authorisation path, the buyer at checkout holding a card, is the last thing to degrade and the first thing to recover.
Why this matters for cross-border payment infrastructure
This problem is sharper in cross-border payments than almost anywhere else, for a simple reason: we have no idea when our peak is.
A domestic platform knows roughly when its rush comes. But an Indian exporter's buyers are in London, New York, Dubai, and Singapore. A SaaS company's renewals fire on a US billing cycle. A marketplace's demand spikes on a Gulf holiday nobody in the Bangalore office has in their calendar. Our load curve is set by other people's calendars, in other people's timezones, and increasingly by traffic that has nothing to do with commerce at all.
An international buyer at checkout is the most expensive visitor a merchant will ever have. They have been acquired, convinced, and are holding a card. If the platform is saturated at that moment, that entire acquisition cost is written off, and unlike a domestic shopper, an overseas buyer rarely comes back to retry.
Reliability in cross-border payments is not about surviving your own peak. It is about surviving someone else's.
As an RBI-authorised payment aggregator running both inbound collections and outbound payouts on one stack, this is the standard we hold ourselves to for every merchant trying to receive international payments through us.
If you are evaluating an alternative to Stripe, Skydo, or xFlow in India, it helps to know what each actually offers. Stripe brings mature, global-scale card processing built over a decade, a genuine strength no Indian aggregator can claim to match yet. Skydo and xFlow, by contrast, are built around multi-currency accounts, holding foreign currency, not processing a card at checkout. PayGlocal is built to do both: card processing rails and multi-currency accounts, plus payouts, domestic and cross-border, on one RBI-authorised stack. The architecture in this post, edge absorption, elastic scaling, admission control, is what backs the card processing side of that infrastructure.
Conclusion
PayGlocal runs international and domestic payments on one RBI-authorised stack, with acceptance across 180+ countries. We build for the traffic we cannot predict, because in cross-border payments that is most of it. This is what payment gateway scalability looks like in practice: not standing capacity held in reserve, but elastic infrastructure that absorbs the surge and recovers on its own.
If you are embedding cross-border payments into your product, or need to accept and receive international payments reliably, our APIs are at docs.payglocal.in
Frequently Asked Questions
By absorbing it as far from the payment core as possible. A globally distributed edge network terminates and evaluates incoming traffic close to its origin, shedding what cannot be served, so that only shaped, legitimate traffic reaches the authorisation systems. Behind the edge, a stateless API layer scales out elastically without human intervention, and admission control ensures capacity is reserved for genuine transactions rather than exhausted on requests that have already timed out.
Peak TPS in isolation means very little. What matters is the ratio between baseline and peak, and whether the platform can absorb that ratio without degrading, and without paying for peak capacity permanently. A platform that sustains 48,000 TPS at peak but is provisioned for it all year round is badly engineered. Elastic capacity, not standing capacity, is the goal.
Edge computing is usually discussed as a latency optimisation, but for payments it is equally a resilience mechanism. A distributed edge has a far larger capacity envelope than any single origin region, so it can absorb surges that would overwhelm a centralised stack, and it does so geographically far away from the systems that actually move money. For cross-border payments it delivers both benefits at once: lower checkout latency for international buyers, and protection for the payment core.
Through four properties: absorption at the edge, stateless services that scale out automatically, admission control that fails excess requests fast rather than slowly, and per-merchant isolation so that one tenant's surge cannot consume another's capacity. Load is then shed in a defined order, with the buyer-facing authorisation path degraded last and recovered first.
Yes, directly. A provider that must hold permanent peak capacity to feel safe carries that cost every day of the year, and recovers it in the rates merchants pay. A provider that can absorb surges elastically keeps its baseline cost low, which is what makes competitive cross-border pricing possible in the first place.
On a well-engineered platform, a transaction that cannot be completed within its budget is rejected immediately and cleanly, so the merchant can retry or route elsewhere. The failure mode to avoid is the transaction that is accepted and then hangs. A payment that fails fast is recoverable; a payment that hangs is not.
As an RBI-authorised payment aggregator running both inbound collections and outbound payouts on one stack, this is the standard we hold ourselves to for every merchant trying to receive international payments through us.