𝐘𝐨𝐮𝐫 𝐀𝐏𝐈 𝐢𝐬 𝐬𝐥𝐨𝐰. 𝐖𝐡𝐚𝐭 𝐝𝐨 𝐲𝐨𝐮 𝐨𝐩𝐭𝐢𝐦𝐢𝐳𝐞 𝐟𝐢𝐫𝐬𝐭?

When API response times start climbing, the first instinct is often to add more resources, introduce caching, or start rewriting code.

But a slow API doesn’t always mean a slow application.

The bottleneck could be hiding almost anywhere: → 𝐀𝐧 𝐮𝐧𝐨𝐩𝐭𝐢𝐦𝐢𝐳𝐞𝐝 𝐝𝐚𝐭𝐚𝐛𝐚𝐬𝐞 𝐪𝐮𝐞𝐫𝐲 → 𝐀 𝐦𝐢𝐬𝐬𝐢𝐧𝐠 𝐢𝐧𝐝𝐞𝐱 𝐨𝐫 𝐍+𝟏 𝐩𝐫𝐨𝐛𝐥𝐞𝐦 → 𝐁𝐥𝐨𝐜𝐤𝐢𝐧𝐠 𝐈/𝐎 𝐢𝐧𝐬𝐢𝐝𝐞 𝐭𝐡𝐞 𝐚𝐩𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧 → 𝐇𝐞𝐚𝐯𝐲 𝐬𝐞𝐫𝐢𝐚𝐥𝐢𝐳𝐚𝐭𝐢𝐨𝐧 → 𝐀 𝐬𝐥𝐨𝐰 𝐭𝐡𝐢𝐫𝐝-𝐩𝐚𝐫𝐭𝐲 𝐬𝐞𝐫𝐯𝐢𝐜𝐞 → 𝐍𝐞𝐭𝐰𝐨𝐫𝐤 𝐥𝐚𝐭𝐞𝐧𝐜𝐲 𝐨𝐫 𝐭𝐢𝐦𝐞𝐨𝐮𝐭𝐬 → 𝐄𝐱𝐡𝐚𝐮𝐬𝐭𝐞𝐝 𝐝𝐚𝐭𝐚𝐛𝐚𝐬𝐞 𝐜𝐨𝐧𝐧𝐞𝐜𝐭𝐢𝐨𝐧 𝐩𝐨𝐨𝐥𝐬 → 𝐂𝐏𝐔 𝐨𝐫 𝐦𝐞𝐦𝐨𝐫𝐲 𝐩𝐫𝐞𝐬𝐬𝐮𝐫𝐞

And sometimes adding Redis, more workers, or additional infrastructure only hides the real problem instead of solving it.

That’s why I prefer a simple principle: 𝐌𝐞𝐚𝐬𝐮𝐫𝐞 𝐟𝐢𝐫𝐬𝐭. 𝐎𝐩𝐭𝐢𝐦𝐢𝐳𝐞 𝐬𝐞𝐜𝐨𝐧𝐝.

In production backend engineering, performance optimization should be driven by evidence, not assumptions.

I’ve summarized the areas I usually think about when investigating API latency in the post below.