Cache

Caching

A técnica de caching consiste em armazenar dados temporariamente em um componente mais eficiente para agilizar o acesso a informações. Assim, cada vez que um dado é solicitado e está presente no cache, a latência para sua disponibilização é extremamente reduzida.

Em situações de alta demanda, com um volume grande de requisições, a utilização do cache traz ganhos substanciais em termos de performance. O API Manager implementa a funcionalidade de caching para qualquer operação de uma API (com método HTTP GET).

Interceptores Cache Write e Cache Read

O interceptor Cache Write, ao ser inserido no fluxo de resposta de uma determinada operação de método GET, irá criar um cache com base nas configurações informadas. A partir da segunda requisição, o sistema irá utilizar a resposta armazenada em memória. Para isso, basta adicionar um interceptor Cache Read no fluxo da operação:

cache flow

Na configuração do caching, podem ser incluídos atributos do cabeçalho e/ou da URL para determinar unicamente a entrada de cache que deve ser utilizada. Além, é claro, do tempo de expiração do dado armazenado em cache.

cache write

O interceptor Cache Read é responsável por identificar um cache criado com base no cache name informado. Quando uma requisição é enviada para uma operação "cacheada", o interceptor identifica o cache e insere a resposta em memória na chamada. Isso traz ganho de performance, já que a requisição não precisará ser enviada para o backend.

cache read
O nome do cache deve ser o mesmo configurado no interceptor Cache Write.

Cache Invalidation Interceptor

O interceptor Cache Invalidation é responsável por invalidar um determinado cache do sistema , com base no cache name informado. Ao ser inserido em uma determinada operação, o sistema irá localizar e excluir o cache.

cache invalidation

Cache key

As respostas a partir do cache não precisam ser sempre as mesmas, mas podem variar de acordo com elementos pré-definidos. A chave do cache (Cache key) identifica unicamente as respostas armazenadas. Todos os elementos da requisição (URL, headers, query params, etc) que influenciam a resposta precisam fazer parte da chave. Os elementos que não influenciam a resposta podem ser deixados de fora da chave.

A URL é sempre parte da chave.
  • Se a resposta a uma requisição pode ser reusada globalmente — como uma lista de cidades — então a URL já basta como chave. Isto significa que, depois do primeiro acesso a, por exemplo, GET /cities, todos os demais acessos, mesmo que por outras apps ou usuários, receberão a mesma resposta vinda do cache.

  • Se a URL é a mesma, mas a resposta é diferente dependendo do usuário ou app usados (por exemplo, GET /preferences retorna dados diferentes dependendo do usuário envolvido na chamada), então esse usuário/app precisa fazer parte da chave.

  • Outras informações que influenciam a resposta, como query params usados para filtro (ex: GET /products?orderBy=date vs. GET /products?orderBy=price) também precisam fazer parte da chave.

  • Parâmetros de paginação também são candidatos a fazerem parte da chave (ex: GET /products?page=1 vs. GET /products?page=2).

Para informar como a chave do cache deve ser formada, o administrador preenche dois campos, após selecionar o interceptor Cache Write no fluxo de resposta:

cache key
  • O campo Headers to include in cache key deve ser uma lista, separada por vírgulas, de nomes de headers HTTP que devem ser usados para compor a chave. Por exemplo, o valor client_id, access_token faz com que os headers client_id e access_token sejam usados para fazer parte da chave.

  • O campo Query-params to include in cache key é igual ao campo acima, mas especifica nomes de query params que serão adicionados. Nos exemplos acima, a chave do cache poderia levar em conta os query params orderBy, page.

Sub-recursos

Ao buscar no cache por respostas já existentes, o Gateway considerará apenas URLs que sejam exatamente iguais à requisitada. Isso significa que uma regra que configura o cache do recurso /products não configura o cache do recurso /products/{id}; de fato, do ponto de vista da API, os dois são recursos completamente distintos.

Observe, porém, que se for criada uma regra de cacheamento para o recurso /products/{id}, então o Gateway colocará no cache respostas diferentes para /products/123 e /products/456, como é o esperado. Isso significa que produtos populares serão servidos frequentemente a partir do cache, enquanto produtos menos vistos não estarão no cache e serão encaminhados diretamente ao backend.

As regras acima sobre headers e query params que fazem parte do cache também são levadas em conta para recursos, como /products/{id}.

Time-To-Live

Cada regra de cache especifica uma duração de tempo em que o cache é considerado válido. Depois desse tempo, as respostas no cache são descartadas. Observe que os valores são em segundos; tipicamente, um cache de respostas de API pode durar de alguns segundos a algumas horas, não mais do que isso.

Tamanho máximo

Internamente, o gateway possui um limite prático para a quantidade de bytes que ele pode armazenar em memória. O objetivo disso é proteger a infraestrutura do próprio gateway, para que uma resposta demasiadamente grande não ocupe a memória por muito tempo. Em geral, esse limite é grande o bastante para acomodar muitas chamadas de tamanho razoável. Entretanto, se o limite for atingido, novas respostas não serão armazenadas até que algumas sejam removidas.

Atulização de cache

A atualização do cache acontece quando o time-to-live expira e é realizado uma requisição para uma operação que possui os interceptores Cache Write e Cache Read no fluxo. Para invalidar um cache, basta inserir em uma operação um interceptor Cache Invalidation com o mesmo cache name.

Thanks for your feedback!
EDIT
How useful was this article to you?