Commerce and retail
Scale up before sale days and release afterwards. Images go through object storage and the CDN, orders live in a high-availability database, and a WAF guards the front door.
The challenge
- 01Traffic concentrates on a few campaign days.
- 02Serving large image catalogues from app servers slows pages down.
- 03Login and checkout attract credential stuffing and scrapers.
Reference architecture
How it rolls out
- 01
Protect the front door
CDN with WAF and SSL keeps images, scripts and bot traffic away from the origin.
- 02
Separate app and data
Run the app on horizontally scalable servers, orders in the cloud database, carts and sessions in the cache.
- 03
Load-test before campaigns
Load-test at the expected traffic, find the bottleneck and add servers in advance.
- 04
Scale back afterwards
After the campaign, scale back to everyday size and pay only for what you used.
How a customer uses it
A home-goods shop selling across South-East Asia
- Before
- Every big sale slowed the site to a crawl: images took seconds, checkout sometimes failed, and support spent the night apologising.
- After
- Static assets on the CDN, reads split from writes in the database, and a load test plus scale-up a week before. Peak traffic this year was ten times normal and pages still opened within a second.
10×
Campaign peak traffic
< 1 s
Home page load
0
Checkout failure complaints
Design notes
Cache in front
Put product and stock lookups through managed Redis so the database handles writes and essential reads.
Use the HA database
Automatic failover keeps checkout running if a node fails mid-campaign.
Keep images off app servers
Uploads go straight to object storage and are delivered by the CDN.