Caches, CDNs, and Database Indexes: Three Different Ways to Make Reads Fast

Data Systems

When a page loads slowly, teams often say "we need caching" as if that were one thing. It is not. Slow reads can come from different layers, and the fix depends on where the bottleneck lives.

Three tools get mentioned together constantly but solve different problems:

  • database indexes make lookups inside the database cheaper,
  • application or HTTP caches avoid recomputing or refetching data,
  • CDNs move content physically closer to users and shield origins.

Conflating them leads to bad diagnoses and even worse architecture.

Database Indexes: Find Rows Without Scanning Everything

A database index is a data structure, commonly a B-tree, that helps the database find rows quickly without scanning the entire table.

Without an index, a query like this may require a full scan:

SELECT * FROM orders WHERE user_id = 42;

With an index on user_id, the database can jump directly to the relevant part of the data structure.

Indexes are powerful, but not free:

  • they consume storage,
  • they slow down writes,
  • and the wrong index can still leave a query inefficient.

For frontend engineers, the important insight is that some slow APIs are not network problems at all. They are query-shape problems. A filter-heavy dashboard can feel slow because the underlying table access is expensive.

Caches: Trade Freshness for Speed

Caches store already-computed or already-fetched results so future reads avoid expensive work.

Cache locations include:

  • React query caches,
  • browser HTTP cache,
  • Redis,
  • service worker caches,
  • API response caches.

The core tradeoff is always the same: the faster read path becomes, the harder freshness becomes.

const product = await cache.get(`product:${id}`)
if (product) return product

const fresh = await db.products.findById(id)
await cache.set(`product:${id}`, fresh, { ttl: 60 })
return fresh

That is why caching conversations eventually turn into invalidation conversations. Speed is easy. Correctness is hard.

CDNs: Move Content Closer to the User

A CDN caches content at edge locations near users. This reduces geographic latency and protects the origin from repeated requests.

CDNs are ideal for:

  • static assets,
  • images,
  • compiled JavaScript bundles,
  • public pages with cacheable HTML,
  • some API GET responses.

The frontend benefit is obvious: the first byte arrives faster, especially for global audiences.

But CDN design has constraints:

  • per-user personalization reduces cacheability,
  • purge strategies must be correct,
  • browser caches may still outlive the edge purge,
  • and dynamic data needs deliberate revalidation rules.

These Three Layers Stack, They Do Not Replace Each Other

Consider a product page:

  1. HTML and static assets may come from a CDN.
  2. The API response may come from a backend cache.
  3. The underlying query may still depend on a database index.

If the database query is terrible, a CDN only hides the problem for cacheable reads. If invalidation is weak, the caches may be fast but stale. If edge caching is absent, even indexed queries may still feel slow for distant users.

Frontend Tradeoffs to Watch

These are the main product consequences:

  • Indexes affect backend response time but not freshness.
  • Caches improve response time but risk stale UI.
  • CDNs cut network latency but complicate purge and personalization.

Practical frontend responses include:

  • showing freshness hints,
  • using stale-while-revalidate behavior for non-critical data,
  • separating personalized from cacheable content,
  • and instrumenting slow endpoints before guessing which layer needs work.
<p className="text-sm text-zinc-500">
  Showing cached analytics from the last 60 seconds.
</p>

That small line is architecture honesty. It tells the user the system is intentionally trading perfect freshness for speed.

Conclusion

Database indexes, caches, and CDNs all make reads faster, but they attack different bottlenecks. Indexes optimize data lookup. Caches avoid repeated work. CDNs reduce distance and absorb traffic.

Strong engineering means diagnosing which layer is actually slow before reaching for the wrong fix. Fast systems are layered systems, not systems that yell "cache it" at every problem.