---
title: "Comment by Daniel Collins on \"Before You Cache That .NET Endpoint, Inspect the Query\" | Hashnode"
description: "This is a useful reminder that caching is often treating the symptom rather than the cause. I have seen a slow endpoint get faster with Redis, only for the same"
url: "https://hashnode.com/posts/before-you-cache-that-net-endpoint-inspect-the-query/6af3a9bf06e0902fc89b060d/comment/6af404454d90c3845e28b22a"
---

[Discussion](https://hashnode.com/posts/before-you-cache-that-net-endpoint-inspect-the-query/6af3a9bf06e0902fc89b060d)

Comment [Before You Cache That .NET Endpoint, Inspect the Query](https://hashnode.com/posts/before-you-cache-that-net-endpoint-inspect-the-query/6af3a9bf06e0902fc89b060d)

[Daniel Collins](https://hashnode.com/@fabbalancecheckuae)

[1d ago](https://hashnode.com/posts/before-you-cache-that-net-endpoint-inspect-the-query/6af3a9bf06e0902fc89b060d/comment/6af404454d90c3845e28b22a)

This is a useful reminder that caching is often treating the symptom rather than the cause. I have seen a slow endpoint get faster with Redis, only for the same slow query to show up again as soon as the cache missed or the data grew.

I agree with Rishabh about keyset pagination too — Skip and Take feel harmless in development with a few hundred rows, then the offset cost grows with every page. Checking the query plan and looking for N+1 queries before adding a cache has saved me a lot of time.

The other question I now ask first is how fresh the data needs to be. If the answer is seconds, a cache with a short lifetime can work well. If it needs to be exact, fixing the query or adding the right index is usually the better investment than managing invalidation later. Thanks for the practical framing.