Why Great Systems Don't Query the Database Every Time

(Caching Explained)

A few years ago, our team investigated a feature that had suddenly become slow.

The first reaction was predictable: "The database must be the problem."

But after digging into the metrics, the database wasn't overloaded. The application was simply asking the same question thousands of times.

Nothing was wrong with the database. The architecture was doing unnecessary work.

That's when you realize an important lesson: A database should be your source of truth — not your first stop for every request.

Imagine an online store. Thousands of users open the same product page every minute. The product name, images, and price barely change.

If every request goes straight to the database, you're repeatedly fetching identical data.

Now add a cache in front of it.

• The first request reads from the database and stores the result.
• The next thousand requests are served directly from the cache.
• The database handles fewer queries.
• Response times improve.

The system scales further without adding more database capacity.

Of course, caching isn't just about speed. It's about deciding what can be temporarily reused and when it must be refreshed.

That's where the real engineering trade-offs begin.

One principle I always come back to is this: Great systems don't make databases faster. They make databases work less.

Where have you seen caching make the biggest impact — API responses, database queries, CDN, or the frontend?