Should I cache the data or hit the database?

Question

I have not worked with any caching mechanisms and was wondering what my options are in the .net world for the following scenario.

We basically have a a REST Service where the user passes an ID of a Category (think folder) and this category may have lots of sub categories and each of the sub categories could have 1000 of media containers (think file reference objects) which contain information about a file that may be on a NAS or SAN server (files are videos in this case). The relationship between these categories is stored in a database together with some permission rules and meta data about the sub categories.

So from a UI perspective we have a lazy loaded tree control which is driven by the user by clicking on each sub folder (think of Windows explorer). Once they come to a URL of the video file, they then can watch the video.

The number of users could grow into the 1000s and the sub categories and videos could be in the 10000s as the system grows.

The question is should we carry on the way it is currently working where each request hits the database or should we think about caching the data?

We are on using IIS 6/7 and Asp.net.

Answer 1

First, ensure that the code is partitioned in such a way that your data provider can be switched easily. We're talking interface segregation and the other SOLID principles here.

Next you need to know the answer to the following:

1) Will the data change frequently? 2) Does the application poll your REST service frequently to get these updates? 3) Is the database used for other purposess? 4) Are you aware of any current performance issues? 5) Is the data updated by your application and do those updates need reflecting in the app?

The interesting thing is that by using the database, you are technically caching the data already. That's what a database does. A lot of R&D goes into making the database as fast as possible at retrieving data. It uses its own memory cache for frequently used data for example.

So ask yourself what do you hope to gain by swapping cache providers? And What are the current limitations that need addressing?

If you are not currently experiencing any slow downs I'd simply say "no, no need to switch".

It's a really big topic. Caches tend to do really well when the data needs to be geographically distributed, but there is a huge overhead in terms of management.

I'm doing a project at the moment where I'm making exactly the same sorts of decisions.

My solution so far is to use the database only and hit it lots with polling requests from each client. Sounds yucky, but it scales (in testing) far more than I'll need, the code is very simple.

That said, my code uses a sort of repository pattern which abstracts the main application's data provider from the database code. If I wanted to swap in a cache provider like GemFire, it would require a pretty tiny amount of code to do.

Answer 2

There really isn't enough information, as per Thorbjørn's comments.

Caching, when done wrong, can cause you & your users lots of grief. Make sure you need to worry about caching before over-complicating your application.

So, in the absence of information that indicates you really need to cache, don't cache.

[General rule of optimization: If you need to ask if I should do something, the answer is no]*
* It would be a statement, not a question, in most places where the answer is yes.