N°
N°002
Name
12× throughput
Client
Turbo Diesel Engine Parts
Year
2026
Type
Performance engineering
Stack
Prometheus, Grafana, redis_exporter, asyncio, a reproducible load generator
Outcome
7.8 to 95.2 requests per second; p95 3.20 s to 0.43 s at 25 concurrent, with the model and Twilio stubbed
About
The WhatsApp service was correct and slow. Before changing anything we built a load generator that replays real conversation shapes with the model and Twilio stubbed, measured a baseline, and put the numbers in a document. The causes were ordinary once they were visible: a new Twilio client on every request, synchronous calls inside the event loop, no connection pool. Three long-lived clients, an asynchronous path for the slow calls and a pool later, the same test showed 12 times the throughput and a p95 down from 3.20 seconds to 0.43. Prometheus scrapes the app on the internal network, Grafana shows the 11 panels that matter, eight alert rules watch the things that have actually gone wrong before, and WARNING and ERROR lines go to a phone. The live webhook p95 is set by the model, on purpose, and the dashboard says so.
Before and after on the same synthetic load: throughput and p95, with the model and Twilio stubbed
Eight alert rules, each for something that has actually gone wrong before
The fix that mattered most: three long-lived clients instead of a new one per request
Delivery status per message, written by Twilio's status callback: sent, delivered, read, or why not
