Payment gateways in MENA face scaling challenges that are both universal and regionally specific. Universal because database write throughput, connection pool exhaustion, and PSP API rate limits affect every gateway at scale. Regionally specific because MENA's payment rails — UAE's IPP, Saudi Arabia's SARIE, Nigeria's NIBSS NIP — have characteristics that shape the engineering approach differently than US ACH or European SEPA integrations.
The 100K to 1M Transition
At 100,000 transactions per day (~1.2 TPS average, ~5–10 TPS peak), most architectures hold. A well-designed monolith or a small number of services, a single primary database with one or two read replicas, and a single region can handle this load comfortably.
The transition to 1 million per day (~12 TPS average, ~50–100 TPS peak) is where specific components begin to buckle.
Database write throughput
Each authorisation creates at least one database write — the transaction record — and often several more: audit log, balance update, idempotency key. At 100 TPS, that is 100 writes per second across potentially many tables. Primary database write throughput becomes a constraint.
The mitigation before you need read replicas and sharding: identify which writes are in the critical path (must complete before the response is sent) and which are not (audit logs, analytics events). Move non-critical writes to an async queue. This significantly reduces write pressure on the critical path.
For MENA-specific consideration: regulatory audit logging requirements under CBUAE (UAE) and CBN (Nigeria) mean you cannot simply eliminate audit writes — but you can defer them. The audit record must be created; it does not need to be created synchronously in the authorisation response path.
Connection pool exhaustion
At higher concurrency, application instances exhaust their database connection pools. Symptoms look like latency spikes with database CPU at 30% — the database is not overloaded, but application threads are waiting for connections.
PgBouncer or an equivalent connection pooler in transaction mode eliminates this bottleneck. Application instances connect to the pooler; the pooler maintains a smaller set of real database connections. This is one of the highest-leverage optimisations available, and it is appropriate for any MENA gateway approaching this threshold.
The 1M to 10M Transition
At 10 million transactions per day (~120 TPS average, ~500–1000 TPS peak), the single-primary database model reaches its limits for write-heavy workloads.
Read scaling with replicas
Most payment workloads are read-heavy. Authorisation status checks, balance queries, and reporting read far more than they write. Routing read queries to replicas significantly reduces primary load. The engineering requirement is ensuring that read replicas are used for queries that can tolerate replication lag, and the primary is used for queries that cannot.
In MENA markets, real-time balance displays for wallet products are often a regulatory or product requirement — which means the set of queries that cannot tolerate lag is larger than it might be for a card-only gateway. This affects the proportion of traffic that can be offloaded to replicas.
Write scaling with sharding
For platforms where write volume is the constraint, sharding distributes write load across multiple primary databases. Shard by customer or merchant identifier — the identifier that determines which database partition handles a given transaction. The complexity of sharding is in cross-shard operations and ensuring that shard key distribution is even enough to avoid hot shards.
Async settlement
At high volume, the latency budget for synchronous operations becomes very tight. Separate the authorisation decision (low latency, synchronous) from the settlement operation (higher latency, can be async). Authorisation succeeds or fails in milliseconds. Settlement is processed in the background. This decoupling allows each to be optimised independently.
PSP Integration at Scale
Above one million transactions per day, PSP API rate limits become a real constraint. PSPs rate-limit by API key, by merchant, and sometimes by card network. Understanding your PSP limits and how close you are to them is operational work that must happen before you hit them.
MENA-specific PSP landscape: gateways operating in MENA typically integrate with a combination of global PSPs (Stripe, Adyen, Checkout.com) and regional processors (PayTabs, Telr, HyperPay in GCC; Flutterwave, Paystack in Africa). Each has different rate limits, different reliability profiles, and different response time characteristics. Multi-PSP routing is not just a resilience measure — it is often the only way to handle volume at scale.
Mitigation strategies:
- Routing diversification: Spread transaction volume across multiple PSPs. This reduces exposure to individual rate limits and individual degradation events.
- Request batching: Where the PSP supports it, batch authorisation checks or capture requests. Not all PSPs support this for authorisations.
- Async webhooks: If your authorisation flow triggers downstream webhooks, process them asynchronously with a queue rather than inline with the authorisation response.
Load Testing as Engineering Practice
At scale, the only way to find bottlenecks before users find them is load testing. Load tests must be:
- Realistic: Use transaction patterns that match production. A load test with a single merchant and single card network will not find the bottlenecks that appear with multi-merchant, multi-network traffic.
- Sustained: Peak load tests matter, but sustained load at 80% of peak for 30 minutes reveals bottlenecks that one-minute spikes do not.
- Instrumented: Run load tests with full observability active. The database query that is slow at 100 TPS but acceptable at 10 TPS will appear clearly in traces.
For MENA gateways, load tests should also simulate the PSP failure scenarios that are more likely in the regional context — intermittent API timeouts, elevated error rates during peak periods (Ramadan, National Day weekends), and the specific response code patterns of regional processors.
MENA-Specific Scaling Considerations
Ramadan peak traffic
E-commerce and payment volume during Ramadan in GCC and African Muslim-majority markets can be 3–5x normal daily volume. Platforms that have not load-tested at this multiple discover their architecture limits at the worst possible moment. Architecture that handles 500 TPS on a normal Tuesday must handle 1,500–2,500 TPS in the last week of Ramadan.
Multi-currency wallet complexity
MENA payment platforms frequently manage wallets in AED, SAR, EGP, NGN, KES, and USD simultaneously. Multi-currency wallet infrastructure requires careful ledger design to avoid balance consistency errors under concurrent load — a problem that becomes acute at scale. See our guide on ledger design for wallet platforms.
Regulatory reporting pipelines
CBUAE, CBN, and other MENA regulators require transaction reporting that often needs to be near-real-time. At scale, generating these reports synchronously is not feasible. The architecture must include event streaming or CDC (change data capture) pipelines that produce regulatory reporting data asynchronously without adding latency to the transaction path.
If your gateway is approaching a scaling threshold and you are unsure which bottlenecks will surface first, a scalability assessment will identify them before your users do.