Re-architected a platform that collapsed above 5,000 concurrent users
Peak traffic was taking the marketplace down every campaign day. We rebuilt the data and caching layers, cut p95 latency by 88%, and took it to 80,000 concurrent users on a smaller infrastructure bill.
- Client
- Two-sided marketplace, 400k monthly users
- Duration
- 11 weeks
- Team
- 3 engineers, 1 architect
- Delivered
- 2025
Measured impact
What was actually wrong
Every marketing push produced the same result: response times climbed, the database connection pool saturated, and the site went down for the exact hour it mattered most. The team had already tried scaling instances vertically twice, which bought headroom but not a fix.
- Hard failure above roughly 5,000 concurrent users
- p95 page latency of 1.8 seconds, 6 seconds under load
- N+1 query patterns generating 340 queries on the listing page
- Deploys taking 45 minutes with no rollback path
What we built and why
We measured first. Two weeks of profiling identified that four query patterns accounted for 81% of database time, which changed the plan from a rewrite to a targeted re-architecture.
Killed the query amplification
Listing and search paths were restructured into batched, indexed queries with cursor pagination. The 340-query listing page became four queries.
Introduced a real caching tier
Redis for session and hot-entity caching, with tag-based invalidation wired into write paths so cached data has a defined freshness contract rather than a guessed expiry.
Moved rendering to the edge
Public catalogue pages became statically generated with incremental revalidation, so anonymous traffic — 78% of the total — stopped touching the origin at all.
Made deploys boring
Containerised builds, preview environments per pull request, canary releases, and a rehearsed one-command rollback. Deploy time fell to six minutes and now happens several times a day.
“We expected to be told we needed a rewrite. Instead we got a profiling report that showed four queries were the problem, and a fixed plan to deal with them.”
Let us look at your architecture.
Two ways to start, both of them short. Bring the problem, not a specification — the first useful thing we do is tell you what we would build and roughly what it costs.
Book an architecture call
Fifteen minutes, no deck. We map your problem to an approach and tell you what a realistic scope and budget look like.
- A specific technical recommendation
- A budget band you can plan against
- An honest answer if we are the wrong fit
Send a written brief
Prefer to write it down? Email us the shape of the problem and we will reply with a first take, usually under 12 hours.
- Goes straight to an engineer, not a sales inbox
- We reply with an approach, not a brochure
- Attach anything: repos, docs, screenshots