Most companies implement superficial caching which is why we fix caching issues all the time

This article is written by our sponsor nautilus2k.com which is a new startup trying to help other startups building data-driven apps on the Microsoft .NET Core/ Azure tech stack.

This is related to the previous articles:

When your B2B startup has no people, money or resources think out of the box to build your product

How this startup helps you build a scalable app with a minuscule team, on a shoestring budget

If you have been working in software as long as I have, you will be very familiar with caching. There is all kinds of caching implementations on the Microsoft Stack:

• Static & Dynamic caching in IIS
• ASP.NET Classic Page Caching
• In memory caching — either you can implement it yourself, or use built-in support for caching in .NET/ .NET Core
• Caching using a service like Redis — we reached here after a long history of first storing ASP.NET session in a third party caching service, then there was something called Microsoft Velocity which eventually died.

The problem is that no matter what kind of caching you implement, even with all the advances available today, it is still superficial caching.

Let me explain why, I call it that, and what is better than the state of the art available to most companies and developers today.

Superficial Caching

The problem is with what you are caching. The biggest bang for buck happens when you reduce load on your database, by caching data, and using the cache instead of database calls as often as possible.

In this scheme, you are caching the results of a complex query from the database. If any of that underlying data changes, your cache is out of…