Skip to content
Codense
Retail — 400k monthly orders · 2025

A checkout that stopped falling over on campaign days

Peak traffic took checkout down three times in one quarter. We measured where it actually bent, fixed four things, and left the load model behind.

Measured
2025
Checkout p95, before
4.2s
Checkout p95, after
780ms
Peak orders held
2x
Incidents since
None

Example An illustrative case, not a delivered engagement. The figures below are invented and are here so the layout can be reviewed — replace this record with real work before publishing.

The situation

Every campaign day ended the same way: checkout slowed, the queue backed up, and someone restarted workers by hand. The team had been told the database needed sharding. Nobody had profiled production, and the load tests ran against an average request rate that the real traffic shape never resembled.

What we did

We took a baseline in the first week from production traffic rather than from a synthetic average. The bottleneck was not the database: it was a per-request call to a pricing service with no timeout, behind a connection pool sized for a quarter of the concurrency. We fixed the pool, added a budgeted timeout with a cached fallback, moved two write paths onto a queue, and put a load model in CI that replays the real campaign-day shape.

Where it landed

The next campaign day passed without an incident and without anyone watching it. Checkout p95 came down from 4.2s to 780ms under twice the previous peak, and the sharding project was cancelled before it was funded.

Next step

Tell us what is not working.

An hour on a call, no charge and no deck. We will tell you honestly whether this is work we are good at — and if it is not, who to talk to instead.

Reply within
One working day
First call
One hour, free
Notice period
One month, either way
Based in
Odense & Copenhagen