E-commerce
An online store does not receive flat traffic. Most of the year is quiet, then one campaign multiplies load within minutes. The architecture behind this use case spreads traffic across many instances, pulls unhealthy nodes out of rotation, and keeps user sessions consistent while it does.
A Real Story
How this runs in production
Lokamart takes about 40,000 visitors a day. Then a double-date sale arrives and that number is multiplied by twelve inside eight minutes — twice a year, every year.
The architecture is built for that peak, not for the average. Application nodes are added the day before a campaign and given back afterwards; the load balancer pulls a failing node out of rotation before any customer sees an error page.
- traffic spike absorbed
- 12×
- failed checkouts at peak
- 0
- bill in a normal month
- Rp2,3jt
On our first flash sale here I opened the dashboard and there was nothing to do. That was a new experience for our team.
Reference Architecture
Exactly what they run
The plan names below are the same ones listed on the pricing page.
- Load BalancerL7 + stickyHealth checks every 5s, self-renewing TLS.
- Virtual Machines5.xlarge × 4–14Four nodes daily, fourteen during a campaign.
- Managed Databaseg2.large + 2 replicaCatalogue reads split away from transactions.
What You Get
Built for this workload
Automatic health checks
A failing node leaves rotation before a customer notices.
Sticky sessions
A shopping cart survives traffic being moved between nodes.
Self-renewing TLS
Free certificates, and no expiry date to miss.
Built From