North India's May 2025 heatwave pushed Delhi's peak power demand to 8,231 MW on 21 May and India's grid to an all-time high of 270.82 GW. For a Noida D2C brand selling air-coolers and neck fans, search traffic doubled in 36 hours and their Shopify store started timing out at checkout. We had three days to make it fast without tripling the AWS bill. This post is the exact CDN, cache, and autoscaling playbook we shipped, with real ₹ numbers.
The answer in 60 words
Put a CDN in front of every static asset, cache product pages at the edge for 60 seconds, and move your checkout API behind an autoscaling group with a hard cost ceiling. For a Shopify or headless store, that means Cloudflare cache rules, a stale-while-revalidate header, and a scaling policy capped at 4 instances. We did it in 3 days for a modest monthly infra increase.
Why this matters now
The India Meteorological Department put Delhi, Haryana, Punjab, and Uttar Pradesh under heatwave alerts through late May 2025, and Lucknow's met centre issued a red alert for 10 UP districts. When the grid hits records, two things happen to a D2C cooling brand at once: demand for your product spikes, and your own server costs climb because every extra visitor costs compute. The brands that win the heatwave are the ones whose store stays under a 2-second load time while the cheap ones throw 500 errors at the checkout. You can read the Business Standard heatwave report for the meteorology; this post is about the engineering.
The client (specific details)
t3.medium EC2, no CDN on the custom API, images served from S3 without CloudFrontWe have seen the same shape on every weather-driven demand spike — the monsoon ops post for a Mumbai D2C brand covers the supply-side version of this; the heatwave is the traffic-side version.
Where the slowness actually comes from
Most D2C founders assume "the website is slow" means "we need a bigger server." Usually it does not. Here is where the 6.2 seconds was actually going, measured with the Chrome DevTools waterfall and AWS CloudWatch.
| Layer | Before | What was wrong | After |
|---|---|---|---|
| Product images (S3) | 2,400 ms | No CDN, full-size JPEGs, served from ap-south-1 only | 180 ms |
| Storefront HTML | 900 ms | Shopify handles this well; minor theme bloat | 600 ms |
| Custom pricing/EMI API | 6,200 ms | Single EC2, no cache, synchronous DB call per request | 220 ms |
| Third-party scripts | 1,100 ms | 9 marketing tags loading render-blocking | 300 ms |
The headline: 80% of the pain was in two places — uncached images and a single-instance custom API. Neither needs a rewrite. Both are config changes you can ship in an afternoon.
The four layers of a heatwave-proof store
The 3-day fix (copy this)
t3.medium became an autoscaling group: minimum 1, maximum 4, scale-out when CPU crosses 60% for 2 minutes, scale-in after 10 minutes below 30%. The maximum of 4 is the cost guardrail — you cannot wake up to a runaway bill. Verify with a load test (we used k6) hitting 200 requests/second; the group should add an instance within ~3 minutes.async or defer and gated 2 behind a consent click. The storefront's Largest Contentful Paint dropped by 800 ms. Verify in PageSpeed Insights — the "Eliminate render-blocking resources" warning should clear.stale-while-revalidate cache directive is the unsung hero of heatwave commerce. It serves the slightly-old cached page instantly while fetching a fresh copy in the background. Your visitors never wait; your origin server breathes. Set it to max-age=60, stale-while-revalidate=300 on product pages.The cost math
The brand's revenue during the 18-day heatwave window was ₹38 lakh. The extra infra protected orders that would otherwise have abandoned at a timing-out checkout. That is a return most CFOs sign off on in one message. This is the same cost-guardrail thinking we apply on larger builds — see how we sized infra for the logistics fleet-tracking SaaS dashboard on AWS.
What you will need (prerequisites checklist)
- Admin access to your DNS (to point a subdomain at the CDN)
- A CloudFront or Cloudflare account (free tier covers most SMB traffic)
- A small managed Redis (AWS ElastiCache, Upstash, or a self-hosted instance)
- Ability to set HTTP cache headers on your origin (Nginx, Express, or Shopify app proxy)
- A load-testing tool (k6, Artillery, or Apache Bench) to verify before the spike, not during
- An external uptime monitor with WhatsApp or SMS alerts
- An AWS Budgets alert or equivalent so a cost spike is a notification, not a surprise
Common mistakes (each one hurts)
Symptom: "We added a bigger server and it is still slow." Cause: the bottleneck was uncached database reads, not CPU. Fix: cache before you scale. A 60-second Redis cache beats doubling your instance size for read-heavy pages, and costs a fraction.
Symptom: "Our AWS bill tripled during the spike." Cause: autoscaling with no maximum. A bot crawl or a price-comparison scraper can wake 20 instances overnight. Fix: a hard maximum on the autoscaling group (we use 4) plus a CloudWatch alarm when it is hit.
Symptom: "Images load fine for us but customers complain." Cause: you are testing from the office on fibre while customers are on congested mobile networks during peak power-cut hours. Fix: test with throttled 4G in Chrome DevTools and from an external tool that simulates Tier-2 city connections.
Symptom: "The CDN is caching the cart and showing the wrong total." Cause: you cached a personalised page. Fix: never cache the cart, checkout, or account pages. Cache only product, category, and content pages. Set Cache-Control: private, no-store on anything user-specific.
Symptom: "We turned everything off after the heatwave and it broke." Cause: ripping out the CDN and cache once traffic normalised. Fix: leave the CDN and cache on permanently — they cost little at low traffic and your store is faster year-round. Only the autoscaling headroom needs seasonal tuning.
Real example — the Noida air-cooler brand
The brand came to us at 11 pm on a Tuesday in mid-May, mid-spike, with a checkout taking 6.2 seconds and abandonment climbing. We did not rewrite anything. By the next evening, images were on CloudFront and the pricing API had a Redis cache; by day 2, the API was autoscaled with a cost ceiling; by day 3, alarms and budgets were live.
The outcome over the 18-day window: checkout latency held at 220–340 ms even on the two highest-traffic days, cart abandonment dropped from 31% back to its baseline 19%, and the extra infra cost for the month stayed modest. The founder's words: "I thought I needed a new website. I needed four config changes." As Manvi, who leads our QA and reliability work, puts it: a performance audit is cheaper than a rewrite and almost always finds the real bottleneck in config, not code. We applied the same scaling discipline building Radiant Finance's multi-portal platform, and the identical pattern shows up in our web development work.
A note on the "cooling bills" half of the problem
The post title mentions cooling bills for a reason: a heatwave hits your office and server room too. If you self-host anything on-premise, the same week your store traffic spikes, your data-closet AC is fighting 45°C ambient and your UPS is cycling on grid instability. Our standing advice to SMBs: move the customer-facing store to a CDN-fronted cloud setup so a local power cut in Noida never takes your store down. Keep only internal tools on-premise, and even those want a dual-ISP failover. The fully cloud-fronted store stayed up through two local outages during the spike; an on-premise checkout would have gone dark.
FAQ
How much traffic can a CDN absorb before I need to scale my origin?
A CDN serves cached pages without ever touching your origin, so for static and cacheable content the answer is "almost unlimited at SMB scale." Your origin only sees cache misses and uncacheable requests like checkout. That is why caching first, scaling second, is the correct order — most of a 2x traffic spike never reaches your server.
Will a 60-second cache show customers stale prices?
For 60 seconds, at most. For a D2C store that changes prices a few times a day, that is invisible. If you run flash sales with minute-level price changes, drop the cache to 5 seconds on those products or bust the cache on price update via a webhook. Never cache the cart or checkout total.
Shopify already has a CDN. Do I still need CloudFront?
Shopify's CDN covers the storefront it serves. It does not cover your custom microservices — the pricing API, EMI calculator, or pincode-serviceability service you built and host yourself. Those are exactly what falls over in a spike, and they need their own CDN and cache.
What is a safe autoscaling maximum for an SMB?
Start with a maximum of 3–4 instances and a CloudWatch alarm when the ceiling is hit. The maximum is a cost guardrail, not a performance target. If you legitimately need more than 4 instances of a small API, the real fix is better caching or a more efficient query, not more boxes.
How do I test this before the heatwave instead of during it?
Run a load test with k6 or Artillery at 2–3x your normal peak requests-per-second on a staging copy. Watch latency and the autoscaling response. The goal is to discover your breaking point on a quiet Tuesday, not at 3 pm on the hottest day of the year.
What does this cost to maintain year-round?
The CDN and Redis cache cost little at SMB traffic and make your store faster every single day, not just during spikes. Only the autoscaling headroom is seasonal. We leave the cache and CDN on permanently for every D2C client.
Is this Shopify-only or does it work for headless and WooCommerce?
The pattern is platform-agnostic. CDN in front of assets, cache in front of read-heavy APIs, autoscaling with a cost ceiling on dynamic services. We have shipped it on Shopify, headless Next.js storefronts, and WooCommerce. The components change; the playbook does not.
Want a Performance Audit Before Your Next Demand Spike?
We run a 90-minute performance and cost audit on your D2C store — CDN coverage, cache strategy, autoscaling, and a hard cost ceiling. You get a written report with the exact config changes and a fixed-scope quote if you want us to ship them. Typical fix: 3 working days. Suitable for stores doing ₹2 Cr to ₹50 Cr a year.
Book a Performance AuditIf you would rather we just build the resilient version from the start, our web development team ships CDN-fronted, autoscaled storefronts as a fixed-scope engagement. Email us at contact@softechinfra.com and we will send the audit checklist before the call.
