Performance platform: load testing before load became a problem

The client is not named under the contract: a performance marketing platform preparing for a peak campaign with traffic several times above normal. The dev team knew the bottlenecks in theory — queues, the database, ad account API limits — but not in numbers. The task was to get the numbers before launch, not after.

Starting point

The platform pulls data from ad accounts, recomputes it and shows it to clients in reports. In a peak campaign not only interface traffic grows but the volume of data to pull and recompute — and that is what breaks first. There had been no load tests: problems were learned from clients when reports stopped updating.

• No load profile — unknown which requests and in what proportion arrive at peak.
• No thresholds — unclear what counts as "it held".
• Bottlenecks known by feel, not by measurement.
• External integrations with request limits that may run out at peak.

What we did

1. We took a load profile from real logs of the previous campaign: which requests, in what proportion, with which hourly peaks.
2. We fixed target thresholds with the product owner: p95 response time for interface requests and for report recomputation, the acceptable error rate at target load.
3. We built peak scenarios in k6: interface, API, data collection from ad accounts and recomputation — accounting for external integration limits.
4. We ran in steps with monitoring of the database, queues and external calls, raising load until the thresholds broke.
5. We delivered a report with the saturation point, bottlenecks ranked by cost of fixing, and reproducible scenarios.

Outcome

• Every bottleneck found and ranked before the campaign launch: some closed with settings and limits, some went to the development backlog with priorities.
• The team received a reproducible scenario set and runs it after every release touching integrations or recomputation.
• p95 and error rate thresholds became part of the release readiness criteria.
• The load profile is updated from the logs of every campaign — the set does not go stale.

What turned out to matter

Thresholds fixed before the test. Until they existed, discussing results turned into an argument about whether three seconds is "fine". With thresholds the result reads unambiguously: at target load p95 within limits, error rate within limits — passed; if not — here is the level at which it broke and what broke first. The second lesson concerns external integrations: ad API limits turned out to be a bottleneck before the database, and that could not have been seen without scenarios that exercise them.