Every Dashain and Tihar, Nepali ecommerce stores face seasonal traffic spikes — 5× to 10× baseline in three days. Most failures are not the traffic itself; they're unplanned capacity. Seasonal traffic ecommerce nepal survival is decided weeks before the rush: warm caches, realistic connection limits, and a freeze on deploys.
Key Takeaways
- Dashain and Tihar repeat every year — plan capacity against last year's peak, not average load.
- Most outages are database connection exhaustion or payment gateway timeouts, not the web server.
- Warm your caches before the rush; a cold cache under 10× load is a self-inflicted outage.
- Freeze production deploys about seven days before the festival; the only change you want is a rollback.
- Load-test against staging with a realistic mix of product pages, search, and checkout — not just the homepage.
- Have a pager plan and a rollback path; the person who built the feature should be reachable during the rush.
What seasonal traffic means for a Nepali ecommerce store
Seasonal traffic is not a marketing abstraction. Dashain and Tihar reliably push order volume and concurrent sessions to multiples of baseline, and the peak is compressed into three or four days. The mechanism that breaks is almost always the same: a shared resource runs out before CPU does — usually database connections, PHP-FPM workers, or a payment gateway that starts timing out.
The timing is predictable. Dashain falls in September or October, Tihar follows weeks later, and both drive gift-buying, clothing orders, and food delivery. What is less predictable is the magnitude. An influencer post, a flash sale, or a competitor's outage can double the spike again within an hour. A store that handled last year's rush can still fall over if this year's peak lands differently.
For a store in Kathmandu or Pokhara, the pattern is familiar: 300 sessions on a normal day becomes 2,500 during the rush. Orders per hour climb from dozens to hundreds. The checkout is where the damage shows, because it touches the database, the inventory check, and the payment gateway in one synchronous chain.
Why it matters in production
The cost of failure during the rush is not just lost sales — it is trust. A checkout that times out at Tihar teaches a customer to buy from a competitor next year. The production failure mode is usually cascading: one exhausted pool blocks requests, which pile up in front of it, which makes the next layer in the chain time out, and the whole store slows to a crawl.
We have seen the same sequence more than once. PHP-FPM runs out of child processes, so NGINX queues requests. The database hits max_connections, so queued requests wait on a connection that never comes. The payment gateway, called synchronously at the end, times out because the whole request has already consumed two seconds. The user sees a spinner, then an error, then leaves.
The fix is cheap if you do it before the rush and expensive if you do it at 9pm on the first day of the festival. That is the whole argument for planning: the failure is predictable, and so is the preparation.
When you actually need to plan for it — and when you don't
Not every store needs a load-testing rig or an autoscaling group. If your store serves a few hundred sessions a day and peaks at double that, a cache plugin and a higher database connection limit may be enough. The need for serious planning starts when baseline is already high, or when the peak is 5× or more, or when checkout touches real inventory and a live payment gateway.
A small WooCommerce site on shared hosting has different problems than a custom Laravel store. The shared-hosting store may simply need to move off shared hosting before the rush. The custom store may need a read replica and a queue. A WordPress store built with a page-builder is often slower at the database layer than it looks, because the page content is assembled from many rows per request.
How festival traffic actually moves through the stack
A single page view is a chain of requests — browser to CDN, CDN to origin, origin to database — and the slowest link in that chain determines the user's experience. Caching collapses the first two links; the database and payment gateway remain the ones you cannot fully cache. If either of those saturates, the whole chain stalls.
The browser hits the CDN first. A cached product page returns in milliseconds and never reaches your server. A cache miss goes to the origin: NGINX accepts the connection, passes it to PHP-FPM, which runs the application code, which queries MySQL or Postgres, and finally calls the payment gateway. Each hop has a limit, and a rush finds the lowest one.
This is why inventory integration matters during the rush. If every add-to-cart checks live stock in a remote system, you have added another synchronous hop to the critical path. During a spike, that hop is often the first to time out.
Step-by-step preparation
The preparation sequence matters more than any single setting. Start with a baseline, then warm caches, then freeze deploys, then test. Here is the order we use when we prepare a store for Dashain or Tihar.
- Profile last year's peak. Pull real numbers from logs and analytics: sessions per day, orders per hour, peak concurrent database connections, slowest endpoint. If you don't have logs, start recording them now.
- Load-test against staging. Use k6, Locust, or ApacheBench with a realistic mix: homepage 40%, product pages 30%, search 10%, cart and checkout 20%. Never load-test production during the rush.
- Review and raise connection limits. Check PHP-FPM
pm.max_children, MySQLmax_connections, Redismaxmemory, and NGINXworker_connections. Raise them to match the tested peak, not guesswork. - Warm caches. Crawl the top 200 product and category pages so the CDN and object cache are hot before traffic lands. A cold cache under 10× load is a self-inflicted outage.
- Freeze deploys. No feature changes in the seven days before the rush. If a critical fix must go out, have a tested rollback ready.
- Set alert thresholds. Alert on response time, error rate, connection saturation, and disk space. You want the alert before the customer sees the error.
- Prepare a pager plan. Name who gets called, and list the first three checks: error log, slow query log, connection counts.
Configuration that matters
The settings that fail first are the ones with hard limits: PHP-FPM child processes, MySQL connections, Redis memory, and NGINX worker connections. Raise them deliberately, and only after a load test shows the real peak. Here is a short PHP-FPM pool snippet tuned for festival load.
; php-fpm.d/www.conf — festival-load settings
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.max_requests = 500For NGINX, check worker_connections against your expected concurrent connections — the default is often fine for a small store but too low for a spike. See the NGINX worker_connections documentation and the PHP-FPM configuration reference for the exact directives and defaults. The point is not to tune blindly; it is to test, then set limits above the tested peak with headroom.
How to verify it works
The only honest verification is a load test that reproduces the peak, not a script that hits the homepage a hundred times. Watch response time percentiles and error rate, not just requests per second. A store can serve 1,000 requests per second with a median of 200ms and still fail if the 95th percentile is 4 seconds and checkout errors are climbing.
Run the test, then check the slow query log, the PHP-FPM status page, and the Redis INFO output. If the slow query log shows the same query over and over, fix the query or cache its result. If Redis is evicting keys, you have a memory ceiling, not a CPU problem. Verification is complete when the tested peak runs for ten minutes without a connection error and without a single checkout timeout.
Failure modes and how to debug them
When the site slows down during the rush, the first check is not the code — it is which resource is saturated. Open the error log, check the slow query log, and look at connection counts before touching anything else. The error string Too many connections in MySQL tells you the database pool is exhausted; a wall of 504 Gateway Timeout from NGINX usually means PHP-FPM or the upstream is stuck.
The diagnostic order we use is: first, CPU versus memory versus connections on the app server. Then the PHP-FPM status page for active processes and queue length. Then the MySQL processlist for long-running queries. Then Redis INFO for evictions. Then the payment gateway dashboard for its own latency. Each signal rules out a layer, and the fix is usually at the layer you least expected — a missing index, a synchronous external call, or a cache that never warmed.
Cost and operational overhead
Preparing for a festival rush costs engineer time more than anything else. A little time spent before the rush is far cheaper than diagnosing an outage at 9pm on the first day of Tihar. Cloud costs scale with instance size, egress, and storage class; confirm current figures with your vendor's calculator or ask us for a review. The biggest hidden cost is the opportunity cost of downtime — sales lost forever, not just delayed.
Operationally, the overhead is the pager plan, the monitoring, and the discipline to freeze deploys. That is not expensive. What is expensive is the alternative: a store that survives eleven months and dies in the one month that pays for the other eleven.
Security considerations
A traffic spike is also a target. Scrapers, card-testing bots, and DDoS attempts all arrive with the rush. Rate limiting and a WAF matter as much as capacity. If you process card payments, the PCI DSS scope grows with the traffic — keep card data out of your logs, and make sure the payment gateway call is the only place card details appear.
Bot traffic is the quiet killer. A card-testing script can hammer checkout with thousands of failed transactions, exhausting both your payment gateway limit and your fraud team's patience. Rate-limit checkout by IP and device fingerprint, and alert on abnormal failure rates before the gateway flags your account.
Common mistakes
- Deploying a new feature during the rush because it is "small". Small deploys break things too.
- Not warming caches, then wondering why the first hour of traffic feels like a DDoS.
- Load-testing only the homepage, which misses the checkout and database bottlenecks.
- Ignoring mobile users, who are often the majority during festival shopping.
- Setting no alerts, so the first sign of trouble is a customer complaint on social media.
- Having no rollback plan for the one deploy that did go out.
A concrete realistic scenario
Imagine a Kathmandu pashmina and gift store on a custom Laravel app. Baseline is 300 sessions a day. During Tihar, an influencer posts about the store, and traffic hits 2,500 sessions in 48 hours. Checkout starts timing out. The error log shows SQLSTATE[HY000]: Too many connections. MySQL max_connections is 50, and the payment gateway is adding 2 seconds to every order.
The fix sequence is: raise max_connections, add a read replica for product queries, warm the CDN cache, queue order confirmation emails so they don't block checkout, and freeze deploys for the rest of the rush. The store survives, but the real lesson is that all of this could have been done in October instead of mid-Tihar. That is the kind of review we do before the rush — see how we built ecommerce for Royal Trek Nepal to understand the preparation involved.
Alternatives compared
There is no single right answer for every store. The right approach depends on baseline traffic, team size, and how much of the stack you control. The table below summarises the trade-offs.
| Approach | Best for | Failure mode | Operational overhead |
|---|---|---|---|
| Scale up (bigger VM) | Small stores, quick win | Still a single point of failure | Low |
| Scale out (multiple app servers) | Mid to large stores | Session and state sync issues | Medium |
| CDN-first (cache everything) | Read-heavy catalog | Stale prices or stock | Low to medium |
| Managed platform | WordPress/WooCommerce | Vendor limits, less control | Lowest |
| Code optimisations (query cache, queue) | Any store with a real bottleneck | Misses the actual bottleneck | Engineer time |
In short: the rush is predictable, the failure modes are known, and the preparation is cheap compared with the cost of a dead checkout. Profile last year's peak, warm the caches, freeze deploys, test against staging, and keep the pager close. Our team can help you run that review, tune the limits, and sit with you through the first day of the rush — see our ongoing maintenance work or tell us about your store.
People also search for
0 comments
Be the first to share your thoughts.
Leave a comment
Replying to — cancel