The 200ms Promise: How to Rescue an API That's Bleeding Latency
performance databases caching
The 200ms Promise
Your PM demos the app to investors. Every API call takes 2 seconds. You have one weekend to fix it.
The Demo That Almost Killed the Company
It was a Thursday afternoon, and the conference room smelled like dry-erase markers and anxiety.
Your PM was live-demoing the app to a table full of Series A investors. Fourteen months of engineering effort, three all-nighters, one rewrite. This was the moment.
She clicked Load Dashboard.
The spinner appeared.
It kept spinning.
Two seconds passed. Then two more. The investor in the corner glanced at his phone.
“Sorry, our demo environment is a bit slow,” your PM said, smiling.
But it wasn’t the demo environment. It was production. You knew this because you were watching the metrics from the hallway, and the same API call that just took 4.2 seconds in that room was averaging 3.8 seconds for every real user.
You had one weekend. Not to rewrite the system — to find the actual problem and fix it.
This is that story.
Why Fast Systems Go Slow
Before you can fix latency, you need to understand what creates it. APIs don’t randomly become slow — they slow down for specific, diagnosable reasons.
Here is the typical failure chain:
User request arrives
→ No cache → hits application layer
→ Application fires 1 query per item (N+1)
→ Each query hits unindexed columns
→ DB does full table scans
→ Connection pool is saturated
→ Requests queue behind each other
→ User sees 4-second responsePremium Content
Unlock the full article along with everything else in the archive — all in one place.