Quick answer: Ecommerce peak traffic in the UAE breaks the dynamic path, not the homepage: search, cart, checkout and payment callbacks. Size the peak from last year’s busiest hour, load test six to eight weeks out, cache at the CDN, ask payment providers about rate limits in writing, and rehearse a peak-day runbook.
White Friday is the one week of the year when a UAE online store gets the traffic its marketing team has been asking for, and the week most likely to expose every shortcut in the platform underneath. Pages that load in two seconds on a Tuesday take ten under a campaign spike; checkouts time out; the payment provider starts refusing requests; stock oversells. None of this is bad luck. It’s capacity, caching and process that were never tested at the volume the campaign was designed to create. This article covers how to size the peak, test for it, and run the day itself.
Sources: Flowwow and Admitad analysis of 4.5 million November orders, via Khaleej Times · AppsFlyer, via Khaleej Times · Deloitte and 55 for Google, Milliseconds Make Millions · Stripe rate limits documentation
What actually breaks under ecommerce peak traffic
The homepage rarely falls over. It’s cached, it’s light, and everybody looked at it during the build. What fails is the dynamic path a shopper takes once they are interested: search, filters, the cart, stock checks, the checkout, the payment callback and the order hand-off to the warehouse. Each of those touches a database or a third party, and each one has a ceiling that nobody measured.
Demand is concentrated, too. A Flowwow and Admitad study of more than 4.5 million November orders found that monthly online purchases rose about 10 per cent across MENA, but White Friday itself drove a 40 per cent jump in gross merchandise value. Traffic doesn’t spread itself over the month; it arrives when the email lands and the influencer posts.
Source: Khaleej Times, UAE shoppers during White Friday 2025
| Component | How it fails under peak | Early warning | The fix |
|---|---|---|---|
| Search and filters | Uncached queries hit the database for every keystroke and facet | Search latency climbs before anything else | A dedicated search service, cached popular queries, debounced input |
| Cart and stock checks | Row locks on popular products; overselling when two orders reserve the last unit | Database connection pool near its limit | Short reservations with expiry, stock counters outside the main database |
| Checkout | Slow calls to tax, shipping-rate and fraud services stack up until requests time out | Checkout step times drift from seconds to tens of seconds | Timeouts and fallbacks on every external call; precomputed delivery options |
| Payment callbacks | Webhooks arrive faster than the app processes them; orders stay “pending” | Growing gap between payments captured and orders confirmed | Acknowledge fast, process from a queue, make handlers idempotent |
| ERP, warehouse and courier sync | Synchronous calls to back-office systems block the order flow | Order confirmation slower than payment | Move every back-office update to an asynchronous queue |
| Third-party scripts | Chat, reviews, tag managers and personalisation slow every page | Page weight and main-thread time rise on campaign pages | Audit scripts, defer them, and be ready to switch them off |
If your store runs on a hosted platform such as Shopify or Salla, the core is the platform’s problem, and the big ones are built for this: Shopify merchants peaked at USD 5.1 million in sales per minute on Black Friday 2025. Your risk moves to everything you bolted on: apps, custom scripts, the ERP connector and the payment and BNPL integrations.
Source: Shopify, Black Friday Cyber Monday 2025 data
Size the peak before you test it
A load test without a target is theatre. Start from your own analytics: the busiest hour of last year’s peak, sessions in that hour, pages per session and conversion rate. Then ask marketing what this year’s campaign is designed to do, and turn that into a multiplier. Traffic also arrives in bursts inside the hour, so engineering targets should be set for the busiest minute, not the hourly average.
Illustrative only. Assumes the busiest minute runs at twice the hourly average. Each page usually triggers further API calls (cart, stock, recommendations), so multiply the first figure by your own ratio from a real session trace before setting test targets.
The three numbers are your test targets. The first is the origin capacity to prove; the second is what the database, stock logic and order pipeline must sustain; the third goes to your payment provider. Run it again with the CDN slider at zero: that’s what happens when a change breaks caching on the morning of the sale.
Load testing that tells the truth
Most failed load tests fail by being too kind: the homepage only, no cart activity, an environment smaller than production. A useful test reproduces a realistic journey mix and pushes until something breaks, so you know which component gives way first and at what multiple of normal traffic.
A useful test reproduces a realistic journey mix and pushes until something breaks, so you know which component gives way first and at what multiple of normal traffic.
- Browse-heavy scenario. Listing pages, search, product pages, with the cache behaving as it will on the day.
- Checkout-heavy scenario. Add to cart, apply a coupon, choose a delivery slot, reach payment. This is where databases and third parties are tested.
- Spike scenario. Traffic going from normal to the campaign multiple in a minute or two, the shape an email blast or a creator post produces.
- Soak scenario. The peak held for an hour or more, to expose leaks and connection exhaustion.
Don’t point the load test at your payment provider. Stripe explicitly discourages load testing against its sandbox, where the global limit is 25 requests per second rather than the 100 allowed in live mode and where payment latency is mocked. Its advice is to stub payment calls in your own code and simulate latency sampled from real live-mode calls. The same logic applies to the UAE acquirers and BNPL providers most stores use alongside or instead of Stripe.
Source: Stripe, rate limits and load testing guidance
Measure the 95th-percentile response time for each step, the error rate, database connections and CPU, queue depth and the business result: completed test orders per minute. Run the first full test six to eight weeks out so there’s time to fix what it finds, and run it again after the fixes. If you’re already following our Ramadan and DSF readiness checklist, this is the engineering detail behind its load-testing item.
Put the edge to work: CDN and caching
The cheapest capacity is the request you never serve. A content delivery network answers from a location near the shopper and keeps traffic away from your origin. AWS has run CloudFront edge locations in Dubai and Fujairah since October 2018, and the other major CDNs also serve the region, so cached content doesn’t have to travel from Europe. The scale of the effect shows in Shopify’s own Black Friday 2024 figures: 284 million requests per minute at its edge against more than 80 million per minute reaching its application servers.
Sources: Intelligent CIO, AWS CloudFront edge locations in the UAE · Shopify, Black Friday Cyber Monday 2024 data
Cache aggressively, but cache the right things. Images, scripts, stylesheets and fonts get long lifetimes and versioned file names. Category and product pages can usually be cached for a short time, with the price and stock badge fetched separately or refreshed in the background, so a price change during the sale reaches shoppers within a minute. The cart, checkout, account pages and anything personal are never cached. Bilingual stores have one extra trap: the cache key must include language and currency, or an Arabic shopper gets the English page someone else requested a moment earlier.
Speed is revenue too. Deloitte’s study of 37 retail, travel and luxury brands for Google found that a 0.1-second improvement in mobile load time lifted retail conversion by 8.4 per cent and order value by 9.2 per cent. Google’s own target for Largest Contentful Paint is 2.5 seconds or less at the 75th percentile of page loads. If campaign pages miss that on a quiet day, they will miss it by more under load.
Sources: web.dev, Milliseconds Make Millions · web.dev, Largest Contentful Paint
Payment gateways, BNPL and the limits nobody reads
Payment providers rate-limit their APIs, and the limits are lower than many teams assume. Stripe’s live mode allows 100 requests per second per account globally and, unless documented otherwise, 25 per second for each individual endpoint. Its documentation names flash sales as a common cause of throttling, asks for at least six weeks’ notice before a large increase, and recommends retrying throttled calls with exponential backoff plus randomness so that retries don’t arrive in a single wave.
Source: Stripe rate limits documentation
Whoever processes your payments, a global gateway, a UAE acquirer or a BNPL provider such as Tabby or Tamara, ask these questions in writing before the campaign is booked.
| Ask your provider | Why it matters |
|---|---|
| What are our rate and concurrency limits, per account and per endpoint? | Your calculator figure must sit comfortably below them, including retries |
| How much notice do you need to raise them for a sale? | Stripe asks for six weeks for large increases; others may need longer |
| How are webhooks retried, and for how long? | Missed callbacks leave paid orders stuck; your handler must cope with duplicates |
| Do you have a status page and a named contact for the peak? | During an incident you need an answer in minutes, not a ticket queue |
| Can we run a second provider as a fallback? | A switch to an alternative gateway or method keeps some revenue flowing |
| What fraud rules tighten automatically on volume spikes? | Legitimate peak orders can be declined by rules tuned for normal weeks |
On your side, three habits remove most payment incidents. Give every payment request an idempotency key so a retry never charges twice. Acknowledge webhooks immediately and do the work from a queue. And reconcile payments captured against orders confirmed every few minutes during the peak, with an alert on the gap.
Give every payment request an idempotency key so a retry never charges twice.
How OXEDGE does this
We prepare UAE online stores for their biggest week, from peak sizing to the incident room.
- Peak sizing from your own analytics and campaign plan, turned into written targets for origin, orders and payments.
- Scripted load tests across browse, checkout, spike and soak scenarios, with payment calls stubbed at realistic latency.
- CDN, cache-key and waiting-room configuration for bilingual stores, plus feature flags for everything that can be switched off.
- A peak-day runbook, dashboards and alerting, and an engineer in the incident channel for the campaign window.
Queues, waiting rooms and graceful degradation
Some peaks can’t be served in full, and pretending otherwise is how a store goes down for everyone. A waiting room admits shoppers at a rate the origin can sustain and holds the rest on a branded page. Cloudflare’s Waiting Room, on Business and Enterprise plans, caps total active users and new users per minute; its documentation suggests setting the active-user cap at about 75 per cent of origin capacity.
Sources: Cloudflare Waiting Room overview · Waiting Room configuration settings
Inside the application, decide in advance what to switch off. Recommendations, chat widgets, personalisation and non-essential tracking can go dark behind feature flags without losing a sale. Order placement should write the order and return; stock updates to the ERP, warehouse picking lists, courier bookings and confirmation messages follow from a queue. A queue that’s ten minutes behind is a problem; a checkout that waits for the warehouse system is an outage.
Plan for hostile traffic as well. Cloudflare mitigated 47.1 million DDoS attacks in 2025, more than double the previous year. Put a web application firewall in front of the store, rate-limit login, coupon and checkout endpoints, and use bot management on limited-stock launches, where scripts can empty a product before a human reaches it.
Source: Cloudflare 2025 DDoS threat report
The runbook for the day itself
Technology rarely fails alone; procedures fail with it. Uptime Institute’s 2025 outage analysis found that 85 per cent of human-error outages came from staff not following procedures or from flawed procedures, and that the share caused by procedures not being followed rose by ten percentage points in a year. A peak-day runbook is the procedure, written down before anyone is tired.
Source: Uptime Institute Annual Outage Analysis 2025
- Roles. One incident lead who decides, one person who fixes, one who talks to customers and the business.
- One dashboard. Orders per minute, checkout errors, payment success, origin latency, queue depth and top-product stock-outs on one screen.
- Switches with names. Every feature flag, the waiting room and the fallback payment method, with who may flip each.
- A change freeze. No deploys in the campaign window except an approved fix with a tested rollback.
- Contacts. Account numbers and escalation routes for hosting, CDN, payment providers and couriers, checked the week before.
- Messages in both languages. Pre-approved Arabic and English wording for slow checkout, delayed confirmations and sold-out items.
The single most useful alert is a business one. If orders per minute fall below the expected curve while the technical metrics look normal, something between the shopper and the order is broken, and you want to know within five minutes rather than from a customer on WhatsApp. Our DevOps baseline for small teams covers the monitoring foundation this depends on.
A six-week countdown to White Friday
White Friday 2025 ran from 20 to 30 November, and the US Black Friday it’s built around falls on 27 November in 2026, so the sale window will again sit in late November. Count back six weeks from the first day of your campaign, not from the Friday itself. Tick what’s already done.
Source: Khaleej Times, White Friday 2025 dates
0 of 10
- Peak targets agreed in writing: origin requests per second, orders per minute and payment calls per second
- Payment, BNPL and fraud providers told the campaign dates and volumes; limits confirmed or raised
- Browse, checkout, spike and soak load tests run against a production-sized environment
- The first component to fail under load has been fixed and the test re-run
- CDN caching verified for assets and listing pages, with language and currency in the cache key; cart and checkout never cached
- Back-office sync (ERP, warehouse, courier, messages) runs from a queue, not inside checkout
- Feature flags ready to switch off non-essential scripts and widgets
- Waiting room configured and tested; WAF rate limits on login, coupon and checkout
- Runbook written with roles, switches, contacts and bilingual messages
- Business alert on orders per minute, routed to the people on duty
Eight or more and the store is ready. Below six, start with the first four items: knowing your targets and finding your first point of failure beats every other preparation.
Questions UAE buyers ask
What breaks first on a UAE online store during White Friday?
Usually the dynamic path a shopper takes once they’re interested: search, filters, cart, stock checks, checkout and the payment callback. The homepage rarely falls over because it’s cached and light. Search latency often climbs before anything else.
How do you size traffic for White Friday?
Start from your own analytics: the busiest hour of last year’s peak, sessions in that hour, pages per session and conversion rate. Then multiply by what this year’s campaign is designed to do. The result gives three targets: origin requests per second, orders per minute and payment API calls per second.
When should we load test before White Friday?
Run the first full test six to eight weeks out so there’s time to fix what it finds, then run it again after the fixes. Don’t point the test at your payment provider. Stripe explicitly discourages load testing against its sandbox.
Do payment gateways limit traffic during a sale?
Yes. Payment providers rate-limit their APIs, and the limits are often lower than teams assume. Stripe’s live mode allows 100 requests per second per account globally. Ask your provider in writing about rate and concurrency limits and how much notice they need. Stripe asks for six weeks for large increases.
Does a hosted platform like Shopify or Salla handle White Friday by itself?
The platform core is built for it. Shopify merchants peaked at USD 5.1 million in sales per minute on Black Friday 2025. Your risk moves to everything you bolted on: apps, custom scripts, the ERP connector and the payment and BNPL integrations.
Work with OXEDGE
Find your store’s breaking point in a test, not on White Friday.
We start by sizing your peak from last year’s data and this year’s campaign plan, then load test the journeys that make money. You leave the first conversation with a clear view of what to fix first and how many weeks you have to fix it.
