Case study 03 — Online auction platform · Innova Technologies
Innova's auction engine worked. What no one could answer was how many people could be inside it at once — and what would happen on the day a marquee sale drew a crowd. We instrumented the platform, ran it until it broke, fixed what broke, and ran it again. It now carries the full user mix at 2,000 concurrent users with every journey in the green.
2,000
Concurrent users across the full traffic mix, every journey responding inside target.
20x
Live bidding capacity, from the last clean run before to the last clean run after.
98.75% → 38%
Peak database CPU on the heaviest read path, under heavier load than before.
0
Journeys left in the red at the top of the test range.
Context
Innova runs a live online auction platform: buyers browse inventory, register for a sale, watch lots open, and bid against each other in real time. Traffic is not evenly distributed — it is flat for days and then arrives all at once, in the ninety seconds before a lot closes. The engine had never been tested against that shape of load. It had only ever been tested against the load it happened to receive.
The engagement was not a rescue. Nothing was on fire. The question was whether the platform could absorb the growth Innova was already selling into, and the only honest way to answer it was to generate the crowd artificially and watch what gave way first.
Our approach
Synthetic load only tells the truth if it looks like real traffic. We modelled the test around Innova's own behaviour mix rather than hammering a single endpoint, then escalated it in four steps so we could see exactly where the curve turned.
Representative
Traffic split across six real journeys, weighted the way users actually move: live auction and bidding 30%, inventory 20%, item page 15%, upcoming auctions 15%, pre-bidding 10%, registration 10%.
Escalating
Four graduated runs at a 300-second ramp: 300, 500, 1,000 and 2,000 virtual users. The ramp matters as much as the ceiling.
Instrumented
Every API measured against a two-tier threshold: above 300ms flagged for optimization, above 1s treated as a defect. Database CPU captured on the same clock.
Repeatable
Apache JMeter for scripted journeys, Azure Load Testing for cloud-scale execution. The same suite produced the baseline and the sign-off.
What broke
The application-level runs found the ceiling quickly. At 300 virtual users the platform held. By 500, live auction and bidding had crossed into critical. At 2,000 — the load Innova wanted headroom for — every single journey was over a second, including pages that had looked healthy a moment earlier.
The interesting finding was underneath that. When we stress-tested the live auction on its own, the REST APIs behind it stayed green all the way through the test range. Judged on API response times alone, the live auction looked like the healthiest part of the platform. It was the WebSocket layer that was failing: connections were established without trouble, but initializing an auction and placing a bid — the two actions that constitute the product — were failing more than one time in ten from 90 concurrent users per minute upward.
Two views of the same live auction. Response-code monitoring showed a healthy engine while bidders sat in front of a frozen lot.
What we changed
01
Inventory search was the largest single consumer of database CPU and the reason unrelated journeys degraded in sympathy. Query and index work on that path took peak CPU from 98.75% to under 38% — measured under substantially heavier load than the original run.
02
The WebSocket tier could not hold state for a large concurrent audience on a single instance. Reworking connection handling and message distribution took clean live bidding from 30 users per minute to 600 — the difference between a small sale and a marquee one.
03
Item pages were making more calls, and larger ones, than the view required. Consolidating and caching the supporting requests moved the item page from degrading at 300 users per minute to clean at 1,000.
04
The JMeter scripts and Azure Load Testing configuration were handed over as an asset, not a deliverable. The next release can be measured against the same baseline instead of against an opinion.
How the testing was governed
Verified capacity
The re-test ran the full traffic mix through all four escalating scenarios. Inventory, item pages, pre-bidding, upcoming auctions, registration and live bidding all responded within target at 300, 500, 1,000 and 2,000 concurrent users — including the 2,000-user run where, before remediation, all six had failed together.
Journey
Before
After
Change
Live bidding (initialize + bid)
Before30 users/min
After600 users/min
20x
Inventory search
Before150 users/min
After1,000 users/min
6.7x
Item page
Before270 users/min
After1,000 users/min
3.7x
Upcoming auctions
Before420 users/min
After1,000 users/min
2.4x
"After" figures are the highest load tested, not the point of failure — the platform did not break at the top of the new range.
Impact
Before this engagement, Innova's answer to "how many users can it take?" was an estimate. It is now a measured figure, produced by a repeatable suite the team still owns.
2,000
Concurrent users carried across the full journey mix
20x
Live bidding capacity increase
98.75% → 38%
Peak database CPU on the heaviest read path
6 / 6
Journeys inside target at maximum load, from 0 / 6
<5%
WebSocket failure rate at 600 users/minute, from >10% at 90
1 suite
Reusable load test asset retained by the client
Before
Capacity was an estimate. Live bidding failed above 90 users per minute and nobody knew, because the API tier looked healthy.
After
Full traffic mix green at 2,000 concurrent users, with the real-time layer verified separately at 600 users per minute.
Ongoing
The test suite ships with the platform. Every release can be measured against the same baseline before it reaches a live sale.
Take it with you
The complete write-up: the scenario design and traffic weights, the before-and-after matrices for every API, database CPU and thread-count traces, and the remediation detail behind each number. Useful if you need to take a capacity claim into an engineering or procurement review.
Questions first? contact@matechnologies.net
Full case study
Enter your work email and we will send the complete write-up — scenario design, before-and-after API matrices, infrastructure traces and remediation detail.
Want to know where your own platform stops?