Scalability and endurance testing for an analytics platform
Kept p95 latency flat as audience data and concurrency scaled, proving the analytics dashboards would not slow as customers grew.
p95 latency flat
Problem, approach, and the outcome
The client runs a social-analytics platform that turns high-volume audience and engagement data into dashboards their customers watch closely during live campaigns. When a customer is tracking a launch in real time, a slow dashboard is a broken product.
Both the customer base and the volume of data behind each account were climbing quickly, and the team needed to know performance would scale with them rather than degrade as accounts grew heavier.
The dashboards felt fast in demos, but nobody had confirmed they would stay fast as concurrency rose and each account's data set grew larger. Performance that holds for a small tenant can quietly collapse for a large one.
The real risk was not a single dramatic failure but gradual latency creep, response times drifting up as the platform scaled, until the busiest, most valuable customers felt the worst of it. That kind of degradation rarely shows up until it is already hurting the accounts that matter most.
The platform needed evidence that tail latency stayed flat as both concurrency and data volume scaled, and that it could run for hours without leaking. Sustained, high-percentile performance was the whole question.
We built concurrency and endurance scenarios in k6 and Locust that scaled both simultaneous users and per-account data volume, so the tests reflected how the platform would actually grow rather than a single dimension in isolation. Scaling both axes together is what exposes real-world degradation.
We focused on p95 latency across long-running soak tests, watching the tail rather than the average, because it is the slowest requests that customers actually notice and complain about. Averages hide exactly the pain users feel.
Grafana and Datadog correlated latency against CPU, memory, and query performance as load climbed, so any creep pointed straight at the tier responsible. Across sustained runs the p95 held flat as concurrency scaled, and we handed over parameterised scripts to wire into the release pipeline so regressions get caught in CI. Scalability moved from assumption to evidence.
- p95 latency held flat as concurrency and data volume scaled
- Long-running soak runs confirmed no leaks or slow degradation
- Latency creep traced to the responsible tier via correlated telemetry
- Parameterised scripts wired into CI to catch future regressions
More Quality Assurance & Testing case studies

Load and soak testing for an enterprise cloud platform
Validated a 99.9% uptime SLA under peak load, so the cloud portal and provisioning APIs held through demand spikes without incident.
Read the full case study
Checkout stress and spike testing for a merchant platform
Isolated the true checkout bottleneck and produced a validated capacity model showing three times the throughput headroom the platform believed it had.
Read the full case study
Throughput testing for an IoT data platform
Proved stable ingestion throughput and latency at over a million device messages an hour, so the platform could onboard new fleets with confidence.
Read the full case studyGet a senior architect on the call, first time, every time.
No SDR gauntlet. 30 minutes with an engineer who can scope the problem, name the risks, and give you an honest feasibility call.
