Load testing before campaigns: e-commerce under synthetic peak load

Unknown limits before a major marketing push

The team feared checkout timeouts and search failures under concurrent traffic plus paid social spikes.

Previous peaks survived via emergency scaling—without reliable curves for DB, cache and CDN.

Peak week must not be a surprise experiment—we wanted numbers upfront.

Checkout, search and listing load differently

Not every path scales alike: cart and payment are synchronous; listing uses CDN and Elasticsearch. Bottlenecks were unclear.

Previous peaks showed DB pool exhaustion under search load while CDN kept listing stable—without tests it was unclear where to invest.

Payment provider and cart share DB connections—bottlenecks at one point block the entire checkout.

Target state: latency budgets and documented limits

Before the campaign, spike and ramp-up tests should define clear limits; autoscaling, read replicas and cache tuning validated and documented.

Marketing and shop team wanted credible answers on maximum concurrent users.

Rollback options must be fixed before peak start—not only after first timeouts.

CDN hit rate and DB pool must be observed together under spike.

On-call and marketing need shared thresholds and comms plans before peak start.

Post-campaign review should document curves for the next season—not only verbal lessons learned.

Test architecture from production patterns

We derived k6 scripts from anonymised traffic patterns, defined ramp-up and spikes, and reviewed metrics with app and infra teams. DB pool and cache hit-rate issues were addressed.

War-room protocol and comms plan were aligned with marketing and on-call before campaign start.

Execution aligned with our server load testing service; background in the software development blog category.

Phase 1: baseline and scenarios

Checkout, search and listing scenarios run with different virtual-user profiles. Grafana correlates k6 metrics with DB pool, HPA and CDN hit rate.

Read replicas and connection pool limits were calibrated before spike tests.

Think time and payload sizes follow anonymised production patterns from the prior week.

Baseline tests define p95 latency and error budgets per user journey before the spike.

Phase 2: spike, tuning and runbook

Spike tests simulate paid-social entry traffic; after tuning, latency budgets are written down. On-call receives thresholds and escalation path.

Cache TTL and invalidation were adjusted after bottleneck analysis; HPA thresholds follow test curves.

War-room protocol defines roles for peak hours and communication on threshold breach.

Better a red graph in test week than a red checkout on campaign day.

Stable peak hours without emergency patching

The campaign stayed within agreed latency budgets; error budgets and alerts were aligned with the customer upfront.

Checkout error rate stayed below agreed threshold; search latency rose only moderately under peak load.

Marketing and on-call communicated per runbook—no unplanned war-room escalations.

Post-campaign review documented curves for the next season.

Documented capacity limits

Runbook and curves serve future campaigns; HPA thresholds were adjusted post-test.

Checkout and search paths stayed within agreed p95 latency budgets under peak load.

Versioned k6 scenarios are ready for regression before the next season.

Autoscaling and DB pool adjustments followed data-driven peak evaluation.

War-room protocol and comms plan were aligned with marketing and on-call before campaign start.

Versioned k6 scenarios in the repository enable regression before each major marketing action.

Load testing and support by Groenewold IT Solutions—Made in Germany with close shop and infra alignment.