Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. Star us to help devs discover the project, give it a try, and share your feedback to help improve the product.
You know it is slow because somebody in the product channel posted a screenshot of a spinner with the caption "is this normal".
So you open the codebase, and within ninety seconds you have three theories, two refactors planned, and a strong urge to swap the JSON library.
Optimization is not step one. Optimization is step four, after measurement, after confirmation, and after you have found something that is actually slow.
Cache invalidation, connection pool tuning, pagination cursors, async log buffers, none of that is free. You pay for it forever, in every future debugging session.
Load test the endpoint, look at where the time actually goes, and only then pick a technique from the list below.
The number of times I have watched somebody spend a week optimizing serialization for an endpoint whose real problem was one unindexed query is not a small number.
Okay. Assume you measured. Here are the seven things worth reaching for. Caching, or how to not do the work twice
Caching is the highest leverage trick on this list, because the fastest database query is the one you never send.
The shape is simple. An expensive computation runs once, the result goes into Redis or Memcached, and the next N callers asking the same question get the stored answer.
The catch is that people think caching is a big architectural commitment. It usually is not.
If an endpoint takes 400ms and gets hit 200 times a minute, a thirty second cache removes something like 99% of those database hits, and nobody downstream ever notices data that is half a minute stale.
Short TTLs are underrated because they give you most of the win with almost none of the invalidation pain.
You are not maintaining a cache, you are just refusing to answer the same question 200 times in a row.
Where it gets genuinely hard is when the data must be fresh, and then you are in invalidation territory, which is famously one of the two hard things in computer science.
Start with the boring TTL version. Graduate to invalidation only when the TTL version is provably wrong for your use case. Connection pooling, or stop reintroducing yourself
There is a TCP handshake, usually a TLS handshake, then authentication, then session setup.
You can easily spend more time saying hello to Postgres than you spend querying it.