Before you add a cache, answer one question: what invalidates it? Every caching bug I have debugged came down to skipping that question, or to one of the three mistakes below.
The question to answer first
If answering "what invalidates it?" takes longer than thirty seconds, or ends with "we'll figure that out later", what you're adding is a second source of truth. It will disagree with the first one at some point you can't predict.
Half the caching bugs I have debugged had little to do with the cache itself. Nobody had decided, on the day it shipped, when the data was allowed to go stale.
Caching before measuring
One endpoint I looked at was slow because of an N+1 query. The cache hid that until traffic doubled, and then the query was back with twice the load behind it. Put a cache in front of a slow path you haven't explained and you've only postponed the problem.
No TTL strategy
"We'll invalidate manually" is a promise your future self will break. Even with explicit invalidation in place, set a TTL. It catches the case you forgot to invalidate.
Caching the wrong thing
A common one is caching the final computed result when only one piece of it was expensive. Then a single field changes and you rebuild everything. Cache the expensive piece and assemble the cheap parts around it on each request.
My rule now is to cache late and cache small. It's not exciting, but the pager stays quiet.
Building something like this?
I'm Ahmed Mamdouh, a senior full-stack and AI engineer. I reply within one working day.

Watch queue depth trend, not the current number
Track queue depth over time from day one. The current number says little; the slope tells you whether you have twenty minutes or two.

Scaling 100k WebSocket connections: the reconnect storm
At 100k+ concurrent sockets the count is easy. The reconnect storm is what breaks, and jittered backoff, load shedding and resumable sessions fix it.

How an endpoint got 45 percent faster with no clever code
Twenty minutes with a profiler beat a week of guessing. An N+1, a missing index and a useless cache made an endpoint 45 percent faster.
