Architectural Patterns: Caching

Olá pessoal, tudo certo?

Nesse, volto a falar sobre Architectural Patterns (foram feitos outros posts sobre o tema). Agora, proponho uma breve reflexão sobre o Cahing pattern.

Não é raro vermos a adoção de componentes em arquiteturas de software. Sejam esses componentes desenvolvidos “dentro de casa” ou fornecidos por teceiros, constituem parte importante do plano arquitetural e não podem ser negligenciados.

Do que trata?

De forma simples,

Caching Pattern descreve como reduzir custos de reaquisição de recursos através da não liberação destes imediatamente após utilização.

Os recursos preservam suas identidades, sendo mantidos em alguma forma de armazenamento de acesso rápido. Assim, podem ser reutilizados evitando o custo de reaquisição.

Quando utilizar esse pattern?

Caching pattern é idealmente utilizado em:

Sistemas que acessem repeditamente o mesmo conjunto de recursos e que tenham real necessidade de otimização de performance.

A ênfase na segunda parte da sentença está relacionado aos princípios KISS e YAGNI.

A eficiência desse pattern está na implicação de que a repetição dos processos de aquisição, inicialização e liberação de um mesmo conjunto de recrusos implica em overhead desnecessário.

Aspectos que precisam ser considerados

Sempre que considerar a adoção do Caching Pattern, considere:

• Performance – o principal objetivo consiste na redução do custo associado a repetidas aquisições, inicializações e liberações de um mesmo conjunto de recursos;
• Complexidade – A solução não deve tornar a aquisição e liberação de recrusos mais complexa ou “pesada”. Além disso, a solução não deve adicionar níveis desnecessários de indireção para acessar recursos;
• Disponibilidade – A solução deve permitir que recursos estejam disponíveis mesmo quando os provedores do recurso estejam indisponíveis (temporariamente);
• Escalabilidade – A solução deverá ser escalável com relação a quantidade de recursos.

Modelo geral de implementação

De forma abstrata,

Caching pattern é implementado através do armazenamento temporário de um recurso em buffers de acesso rápido. Quando esse recurso for necessário novamente, usamos o cache para obter e retornar o recurso no lugar da reaquisição no provedor de recursos. O cache identifica os recursos por suas identidades (um ponteiro ou chave-primária);

Quando os recursos em um cache não são mais necessários, então, eles podem ser liberados. A implementação do cache determina como e quando um recurso não é mais necessário.

Estrutura básica

Quando consideramos a adoção do Caching pattern, devemos considerar os seguintes elementos:

• usuário – que utiliza (demanda) um recurso.
• recurso
• cache - que armazena os recursos que os usuários “liberaram”
• provider – fonte primária para os recursos;

Caching em sistemas distribuiídos

Em sistemas distribuídos há duas formas de caching:

1. Client-side – utilizado para reduzir consumo de banda e diniminuir os impactos de latência;
2. Server-side – utilizado quando muitas requisições levam a processamento desnecessário no servidor.

Interessante observar que qualquer uma das duas estratégias pode conduzir a alguma forma de consistência eventual.

Etapas para adoção do Pattern

Se você possui uma arquitetura onde considere adotar o Caching Pattern, recomendo que siga as seguintes etapas:

1. Selecione os recursos – Somente devem ser “cacheados” aqueles recursos que tenham um custo considerável de aquisição e/ou sejam usados com muita frequência.
2. Determine a interface de caching – Quando recursos são “liberados” e  readiquiridos de um cache, este precisa implementar apropriadamente uma interface que indique essas operações;
3. Implemente o cache respeitando a interface determinada;
4. Determine uma estratégia de “despejo” – Os recursos “cacheados” requerem espaço de armazenamento. Quando não utilizados por um longo tempo, manter esses recursos vivos converte-se em uma estratégia ineficiente;
5. Garanta a consistência (mesmo que eventual).

Algumas variações importantes

Transparent Cache

Quando o cache precsia ser integrado de forma “transparente” no sistema. O cache pode ser implementado através de alguma estratégia de “aquisição tardia” (lazy loading).

Read-Ahead Cache

Através da implementação de alguma heurística, o sistema pode antecipar a demanda por um determinado recurso e fazer a aquisição antes de solicitado.

Cached Pool

Uma combinação de Cache e Pool que pode ser utilizada para prover uma solução sofisticada de gestão de recursos.

Quando um recurso precisa ser “liberado” do cache, no lugar de “retornar” para o provider, é colocado em um pool. Assim, o cache serve como um storage intermediário para o recurso e é configurado com um timeout – sempre que expirar, o recurso perde sua identidade e volta para o pool.

A vantagem é uma pequena otimização. (Tão pequena que raramente justifica a complexidade que é adicionada).

Por hoje, era isso;