Performance audit and checkout recovery for ticketing
After two failed on-sales, a ticketing platform needed a focused recovery plan before its next release. We spent two weeks reviewing architecture, performance and developer experience, then ten weeks implementing the three highest-priority fixes.
Screens
The challenge
Checkout crossed six services, but the team could not identify which one caused the slowdown. With no meaningful load test and one quarter before the next release, they needed an ordered set of repairs they could deliver in time.
Our approach
We profiled basket-to-payment under replayed on-sale traffic and ranked each finding by cost to fix against risk removed. The chosen fixes addressed an N+1 query in pricing, a synchronous seat-hold call inside checkout and a cache that was cold at peak demand. We left the load-test harness running in their CI so future changes could be checked before release.
Outcome
- P95 checkout time reduced by 64% under replayed peak load
- Next on-sale handled 9× normal traffic, with about two minutes degraded at opening and no failed payments
- Fifteen findings ranked, with three implemented and twelve available for later planning
- Load-test harness retained in the client's CI to catch future regressions
“The memo alone was worth it — they fixed the three things that mattered and told us honestly which twelve could wait. We have caught two regressions with their load test since, before anyone outside noticed.”Elif Aydın — Backend lead, Perde
Original interfaces and workflows are protected by NDA. Images are UI recreations using synthetic data and figures. Client identity is shared with permission.