10,000 DB queries. Per. API. Call. 💀
We had no idea until latency hit 5 seconds and started laughing at us.
We had a loop that called save() on every entity individually. Looked harmless. Worked fine at low traffic.
Then production came in.
10k entities → 10k DB hits → 5 second response time. Classic N+1 query, hiding in plain sight.
What’s actually happening:
For every order in the list, the code fires a separate DB query. 1 API call with N orders = N+1 DB hits. At low traffic nobody notices — at scale, the DB buckles.
The fix
Instead of save() inside the loop, use saveAll() outside it:
// ❌ N+1 — one DB hit per entity
for (Entity e : entities) {
repository.save(e);
}
// ✅ Batch insert — one DB hit for all
repository.saveAll(entities);One batch insert. Latency dropped. DB stopped crying. 😅
This would’ve slipped into prod unnoticed at low traffic. Scale is what revealed it.
Before making any API public, always ask: “what does this look like at 10x traffic?” ⚡