Antipadrão: respostas a erros de cache

Esta é a documentação da Apigee e da Apigee híbrida.
Confira a documentação da Apigee Edge.

Cache é um processo de armazenamento temporário de dados em uma área de armazenamento chamada cache para referência futura. Armazenar dados em cache traz benefícios de desempenho significativos porque:

  • Permite a recuperação mais rápida de dados
  • Reduz o tempo de processamento ao evitar a geração de dados novamente
  • Impede que as solicitações de API cheguem aos servidores de back-end e, assim, reduz a sobrecarga nos servidores de back-end.
  • Melhor utilização dos recursos do sistema/aplicativo
  • Melhora os tempos de resposta das APIs

Sempre que precisamos acessar alguns dados que não mudam com muita frequência, recomendamos o uso de um cache para armazenar esses dados.

A Apigee permite armazenar dados em um cache no ambiente de execução para persistência e recuperação mais rápida. O recurso de armazenamento em cache é disponibilizado por meio da política PopulateCache, política LookupCache, política InvalidateCache e política ResponseCache.

Nesta seção, vamos analisar a política do cache de resposta. A política de cache de resposta na plataforma Apigee permite armazenar em cache as respostas dos servidores de back-end. Se os aplicativos clientes fizerem solicitações ao mesmo recurso de back-end repetidamente e o recurso for atualizado periodicamente, poderemos armazenar essas respostas em cache usando essa política. A política de cache de resposta ajuda a retornar as respostas armazenadas em cache e, portanto, evita o encaminhamento desnecessário de solicitações aos servidores de back-end.

A política de cache de resposta:

  • Reduz o número de solicitações que chegam ao back-end
  • Reduz a largura de banda da rede
  • Melhora o desempenho da API e os tempos de resposta

Antipadrão

Com a política ResponseCache, você armazena em cache as respostas HTTP com qualquer código de status possível, por padrão. Isso significa que as respostas de sucesso e erro podem ser armazenadas em cache.

Veja uma amostra de política de cache de resposta com configuração padrão:

<!-- /antipatterns/examples/1-1.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServer ResponseCache</DisplayName>
  <CacheKey>
    <Key Fragment ref="request.uri" /></CacheKey>
    <Scope>Exclusive</Scope>
    <ExpirySettings>
      <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec>
    </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
</ResponseCache>

A política do Cache de resposta armazena em cache as respostas de erro na configuração padrão. No entanto, não é aconselhável armazenar em cache as respostas de erro sem considerar sobre as implicações adversas porque:

  • Cenário 1: falhas ocorrem por um período temporário e desconhecido e podemos continuar enviando respostas de erros devido ao armazenamento em cache, mesmo após o problema ser corrigido

    OU

  • Cenário 2: as falhas serão observadas por um período fixo, então será necessário modificar o código para evitar o armazenamento em cache de respostas quando o problema for corrigido

Vamos explicar isso colocando esses dois cenários em mais detalhes.

Cenário 1: falha temporária de back-end/recurso

Considere que a falha no servidor de back-end foi causada por um dos seguintes motivos:

  • Uma falha temporária de rede
  • O servidor de back-end é muito ocupado e não pode responder às solicitações por um período temporário
  • O recurso de back-end solicitado pode ser removido/indisponível por um período temporário
  • O servidor de back-end está respondendo lentamente devido ao tempo de processamento alto de um período temporário etc.

Em todos esses casos, as falhas podem ocorrer por um período desconhecido e podemos começar a receber respostas bem-sucedidas. Se armazenarmos as respostas de erro em cache, poderemos continuar enviando respostas de erro aos usuários, mesmo que o problema com o servidor de back-end tenha sido corrigido.

Cenário 2: falha gradual ou corrigida de recurso

Considere que sabemos que a falha no back-end é por um período fixo. Por exemplo, você está ciente de que:

  • Um recurso de back-end específico ficará indisponível por 1 hora

    OU

  • O servidor de back-end foi removido/indisponível por 24 horas devido a uma falha repentina no site, problemas de escalonamento, manutenção, upgrade etc.

Com essas informações, podemos definir o prazo de validade do cache de acordo com a política de cache de resposta para que as respostas de erro não sejam armazenadas por mais tempo. No entanto, assim que o servidor/recurso de back-end estiver disponível novamente, precisaremos modificar a política para evitar respostas de erro de armazenamento em cache. Isso ocorre porque, se houver uma falha temporária/única no servidor de back-end, a resposta será armazenada em cache e, em seguida, haverá o problema explicado no cenário 1 acima.

Impacto

  • As respostas de erro em cache podem fazer com que as respostas de erro sejam enviadas mesmo após o problema ser resolvido no servidor de back-end.
  • Os usuários podem gastar muito esforço resolvendo a causa de um problema sem saber que ele é causado pelo armazenamento em cache das respostas de erro do servidor de back-end

Prática recomendada

  • Não armazene as respostas de erro no cache de resposta. Verifique se o elemento <ExcludeErrorResponse> está definido como true na política ResponseCache para evitar que as respostas de erro sejam armazenadas em cache, conforme mostrado no snippet de código abaixo. Com essa configuração, apenas as respostas para os códigos de sucesso padrão 200 a 205 (a menos que os códigos de sucesso sejam modificados) serão armazenadas em cache. 
    <!-- /antipatterns/examples/1-2.xml -->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache">
  <DisplayName>TargetServerResponseCache</DisplayName>
  <CacheKey>
    <KeyFragment ref="request.uri" />
  </CacheKey>
  <Scope>Exclusive</Scope>
  <ExpirySettings>
    <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec>
  </ExpirySettings>
  <CacheResource>targetCache</CacheResource>
  <ExcludeErrorResponse>true</ExcludeErrorResponse>
</ResponseCache>
  • Se você tiver o requisito de armazenar as respostas de erro em cache por algum motivo específico, poderá determinar a duração máxima/exata da qual a falha será observada (se possível):
    • Defina o prazo de validade adequadamente para garantir que você não armazene em cache as respostas de erro por mais tempo do que a falha que pode ser vista.
    • Use a política ResponseCache para armazenar as respostas de erro em cache sem o elemento <ExcludeErrorResponse>.

    Faça isso somente se você tiver certeza absoluta de que a falha do servidor de back-end não é por um período breve/temporário.

  • A Apigee não recomenda o armazenamento em cache de respostas 5xx de servidores de back-end.