Load Testing for Saudi Seasonal Peaks: A Checklist

Walk into Ramadan knowing three numbers: the p95 response time of your payment flow at the concurrency you expect on the busiest night, the load at which the platform starts to fail, and which component fails first. Teams that know those numbers before the peak make a capacity decision in a meeting. Teams that do not make it at two in the morning, in production, with customers watching.

This checklist is for CTOs, heads of engineering and heads of QA running Saudi platforms where demand is not flat: banking and fintech apps, payment and wallet services, e-commerce, ticketing, booking and government-facing portals. It covers how to model a Saudi peak, which measures to agree before the first test, the test types that matter, and what changes for the team.

Why Saudi peaks need their own load model

Most load testing guidance assumes one busy season a year. Saudi platforms face several, on two calendars at once.

• Hijri-calendar peaks. Ramadan, Eid al-Fitr, Eid al-Adha and the Hajj season follow the Hijri calendar, so their Gregorian dates move from one year to the next. Plan against the Umm al-Qura calendar, the Kingdom's official calendar, not against last year's dates. The school year is set the same way: the Ministry of Education publishes its calendar by Hijri date, with Gregorian equivalents.
• Gregorian-calendar peaks. Salary day and the White Friday sales arrive on Gregorian dates. Event seasons such as Riyadh Season are announced each year.
• Collisions. Because one set moves and the other does not, peaks stack differently every year. A model built for last year's calendar can miss the year when salary day lands inside the last ten nights of Ramadan, or Eid lands close to the start of term.

The shape of each peak matters as much as its height. Look for these patterns in your own traffic:

• Ramadan: activity shifts later into the evening and after midnight, and stays high for hours. That is a long plateau, not a short spike.
• Before Eid: transfers, gifting, shopping and travel bookings concentrate in the final days.
• Salary day: a burst on balance checks, transfers, bill payments and instalment repayments within hours of salaries landing.
• White Friday and flash sales: a near-vertical spike when a sale opens, often at midnight, with heavy search and checkout traffic.
• Back to school: fee payments, uniform and device purchases, and portal logins cluster around the dates in the Ministry of Education academic calendar.
• Riyadh Season and major events: ticket releases create spikes on booking, payment and confirmation flows. Take event dates from the official Riyadh Season site when you build the year's test calendar.
• Hajj and Umrah: permit, booking and payment journeys carry the load. The Ministry of Hajj and Umrah directs pilgrims to its Nusuk platform to plan Umrah and visits, and the Hajj season runs on a strict "No Hajj Without a Permit" policy. Any platform that integrates with those journeys, from travel operators to payment providers, sees demand follow that calendar.

Step 1: Model the peak from your own data

Do not borrow a number from a conference talk. Build the model from your logs.

• Pull at least the last two of each peak type from production telemetry: requests per second, concurrent sessions, transactions per minute, by hour.
• Break the traffic down by journey: login, balance check, transfer, payment, search, checkout, document download.
• Record the ratio between journeys at peak. A peak with twice the logins and five times the transfers is a different test from one with twice everything.
• Note when each peak started, how fast it climbed and how long it lasted.
• Add the growth since last year: new customers, new channels, new products launched for the season.
• Set the target as the modelled peak plus a safety margin your leadership agrees in writing.

Step 2: Agree the targets before the first test

A load test without targets produces a graph, not a decision. Agree these measures with product, engineering and operations first. ISO/IEC 25010 lists performance efficiency among its nine product quality characteristics; the table turns that characteristic into numbers you can pass or fail.

Measure	What it tells you
p95 and p99 response time per journey at target concurrency	Whether most customers, and the unlucky ones, get an acceptable experience at peak
Throughput in transactions per second	Whether the platform completes work at the rate the peak demands
Error rate under load	Whether requests fail, time out or return wrong results as load rises
Breaking point	The load at which targets are no longer met, and how far it is above the forecast peak
Recovery time after a spike	How long the platform takes to return to normal once a burst passes
Resource saturation	CPU, memory, connection pools, queues and database locks at peak
Dependency latency	Response times of payment, messaging, identity and other external services under load

Step 3: Run the test types the calendar demands

• Load test. Hold the modelled peak with the right journey mix. Confirms the targets.
• Stress test. Push past the peak until targets break. Finds the breaking point and the first component to fail.
• Spike test. Go from normal load to peak in seconds. This is the White Friday midnight and the ticket release.
• Soak test. Hold a high load for many hours. This is the Ramadan night, and it exposes memory leaks, growing queues and connection exhaustion that a thirty-minute test never shows.
• Failover test. Remove a node, a zone or a dependency at peak. Confirms that degradation is controlled and alerts reach the on-call team.

Step 4: Treat dependencies as part of the system

Peaks rarely break the code you wrote. They break the services you call.

• List every external dependency on each critical journey: payment processing, SMS and one-time passwords, identity verification, fraud scoring, notifications, maps.
• Find each dependency's rate limits and contracted capacity. Ask the provider for the numbers in writing.
• Test with stubs that reproduce realistic latency and error rates, then run a coordinated test against the real service where the provider allows it.
• Decide in advance what the platform does when a dependency slows: queue, retry with backoff, degrade the feature, or show a clear message in Arabic and English.

Step 5: Make the environment and data honest

• Size the test environment like production, or scale the results with a documented and agreed method.
• Load production-like data volumes. A query that is fast on ten thousand rows can be slow on ten million.
• Use Arabic names, addresses and search terms in test payloads, not only short Latin strings. Search, indexing and rendering behave differently on real content.
• Mask or synthesise personal data. The Personal Data Protection Law applies to personal data whatever the environment is called.
• Generate load from inside the Kingdom where your customers are, so network paths reflect reality.

Step 6: Move performance into the pipeline

An annual load test tells you about last month's code. Add a smaller performance check to the release pipeline so every release is compared against the previous one on the critical journeys. A release that adds latency to the transfer flow should fail its check in the pipeline, not on salary day.

The pre-peak checklist

1. Peak dates confirmed for the coming year on both calendars, including collisions.
2. Peak model built from your own telemetry, by journey and by hour.
3. Targets for each measure agreed in writing.
4. Load, stress, spike, soak and failover tests run against a production-sized environment.
5. Breaking point known, with a margin above the forecast peak.
6. First failing component identified and fixed, or a mitigation in place.
7. Every external dependency tested or stubbed with realistic behaviour.
8. Degradation behaviour defined and tested for each critical journey.
9. Autoscaling rules tested under spike conditions, including scale-down.
10. Dashboards and alerts checked at peak load, with named on-call owners.
11. Change freeze window agreed for the peak.
12. Performance regression check running on every release.

What changes for the team

• Performance stops being a project. It becomes a standing check in the pipeline with an owner.
• Capacity decisions move earlier. Infrastructure spend is decided weeks before the peak, on evidence.
• Operations gets a runbook built from test results, not from the last incident.
• Product owners see the trade-offs: which feature to degrade first when a dependency slows.

How TQN runs it

Load and performance testing is part of our Quality Engineering practice. We model the peak from your telemetry, generate load that matches the journey mix, run the full set of test types and report each measure with the evidence behind it. AI agents keep the functional regression suite current alongside, so performance tests exercise flows that still work. The platform runs as SaaS, in a private cloud or self-hosted in your environment, and is designed to support PDPL and NCA requirements. For banks, fintechs and payment providers, see our work for financial services.

Start with a QA Readiness Review

The first step is free. Walk us through one platform and its release process, and tell us which peak worries you most. We will show you what we would measure, what the test calendar for the year looks like, and what a fixed-scope pilot would deliver before that peak. Book a QA Readiness Review.