Devo armazenar em cache os dados ou acessar o banco de dados?

Não trabalhei com nenhum mecanismo de cache e fiquei imaginando quais são minhas opções no mundo .net para o seguinte cenário.

Basicamente, temos um serviço REST, no qual o usuário passa um ID de uma categoria (pasta think) e essa categoria pode ter muitas subcategorias e cada uma das subcategorias pode ter 1000 contêineres de mídia (objetos de referência do arquivo think) que contêm informações sobre um arquivo que pode estar em um servidor NAS ou SAN (nesse caso, os arquivos são vídeos). O relacionamento entre essas categorias é armazenado em um banco de dados, juntamente com algumas regras de permissão e metadados sobre as subcategorias.

Portanto, da perspectiva da interface do usuário, temos um controle de árvore carregado preguiçosamente, que é conduzido pelo usuário clicando em cada subpasta (pense no Windows Explorer). Depois que eles acessam um URL do arquivo de vídeo, eles podem assistir ao vídeo.

O número de usuários pode crescer até os 1000s e as subcategorias e vídeos podem estar nos 10000s à medida que o sistema cresce.

A questão é: devemos continuar o modo como está funcionando atualmente, onde cada solicitação atinge o banco de dados ou devemos pensar em armazenar em cache os dados?

Estamos usando o IIS 6/7 e o Asp.net.

Primeiro, verifique se o código está particionado de forma que seu provedor de dados possa ser trocado facilmente. Estamos falando da segregação de interfaces e dos outros princípios do SOLID aqui.

Em seguida, você precisa saber a resposta para o seguinte:

1) Os dados mudam com frequência? 2) O aplicativo consulta seu serviço REST frequentemente para obter essas atualizações? 3) O banco de dados é usado para outras finalidades? 4) Você conhece algum problema de desempenho atual? 5) Os dados são atualizados pelo seu aplicativo e essas atualizações precisam refletir no aplicativo?

O interessante é que, usando o banco de dados, você já está tecnicamente armazenando em cache os dados. Isso é o que um banco de dados faz. Muita pesquisa e desenvolvimento é feita para tornar o banco de dados o mais rápido possível na recuperação de dados. Ele usa seu próprio cache de memória para dados usados ​​com frequência, por exemplo.

Então, pergunte a si mesmo o que você espera ganhar trocando os provedores de cache? E quais são as limitações atuais que precisam ser abordadas?

Se você não está enfrentando lentidão no momento, eu simplesmente diria "não, não há necessidade de mudar".

É um tópico realmente grande. Os caches tendem a se sair muito bem quando os dados precisam ser distribuídos geograficamente, mas há uma enorme sobrecarga em termos de gerenciamento.

Estou fazendo um projeto no momento em que estou tomando exatamente o mesmo tipo de decisão.

Até agora, minha solução é usar apenas o banco de dados e obter muitos pedidos de pesquisa de cada cliente. Parece nojento, mas aumenta (em testes) muito mais do que eu preciso, o código é muito simples.

Dito isto, meu código usa um tipo de padrão de repositório que abstrai o provedor de dados do aplicativo principal do código do banco de dados. Se eu quisesse trocar um provedor de cache como o GemFire, isso exigiria uma quantidade muito pequena de código.

Realmente não há informações suficientes, de acordo com os comentários de Thorbjørn.

O cache, quando feito errado, pode causar muita dor a você e seus usuários. Verifique se você precisa se preocupar com o cache antes de complicar demais o seu aplicativo.

Portanto, na ausência de informações que indiquem que você realmente precisa armazenar em cache, não faça cache.

[Regra geral de otimização: se você precisar perguntar se devo fazer algo, a resposta é não] *
* Seria uma afirmação, não uma pergunta, na maioria dos lugares em que a resposta é sim.