Antipatrón: Respuestas de error de caché

Estás viendo la documentación de Apigee y Apigee Hybrid.
Consulta la documentación de Apigee Edge.

El almacenamiento en caché es un proceso de almacenamiento de datos temporal en un área de almacenamiento llamado caché para referencia futura. El almacenamiento de datos en caché ofrece importantes beneficios de rendimiento por lo siguiente:

Permite una recuperación de datos más rápida.
Reduce el tiempo de procesamiento, ya que evita la regeneración de datos una y otra vez.
Evita que las solicitudes a la API lleguen a los servidores de backend y, por lo tanto, reduce la sobrecarga en estos.
Permite un mejor uso de los recursos del sistema o aplicación.
Mejora los tiempos de respuesta de las API

Siempre que debamos acceder con frecuencia a algunos datos que no cambian con demasiada frecuencia, recomendamos usar una caché para almacenar estos datos.

Apigee proporciona la capacidad de almacenar datos en una caché en el entorno de ejecución para una persistencia y una recuperación más rápida. La función de almacenamiento en caché está disponible a través de la política de PopulateCache, la política de LookupCache, la política InvalidateCache y la política ResponseCache.

En esta sección, analicemos la política ResponseCache. La política ResponseCache en la plataforma de Apigee te permite almacenar en caché las respuestas de los servidores de backend. Si las aplicaciones cliente realizan solicitudes al mismo recurso de backend varias veces y el recurso se actualiza periódicamente, podemos almacenar estas respuestas en caché con esta política. La política ResponseCache ayuda a mostrar las respuestas almacenadas en caché y, en consecuencia, evita reenviar las solicitudes a los servidores de backend innecesariamente.

La política de caché de respuesta tiene los siguientes beneficios:

Reduce la cantidad de solicitudes que llegan al backend.
Reduce el ancho de banda de red.
Mejora el rendimiento de las API y los tiempos de respuesta.

Antipatrón

La política ResponseCache te permite almacenar en caché las respuestas HTTP con cualquier código de estado posible, de forma predeterminada. Esto significa que tanto las respuestas correctas como las de error se pueden almacenar en caché.

Esta es una muestra de la política ResponseCache con la configuración predeterminada:

<!-- /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>

La política ResponseCache almacena en caché las respuestas de error en su configuración predeterminada. Sin embargo, no se recomienda almacenar en caché las respuestas de error sin tener en cuenta las implicaciones adversas debido a lo siguiente:

Situación 1: Se producen fallas temporales durante un período desconocido y seguimos enviando respuestas de error debido al almacenamiento en caché incluso después de que se solucione el problema.
O
Situación 2: Las fallas se observarán durante un período fijo y, luego, tendremos que modificar el código para evitar las respuestas en caché una vez que se solucione el problema.

Veamos esto en dos situaciones más detalladas.

Situación 1: Falla temporal del backend o recurso

Si la falla es en el servidor de backend, se debe a uno de los siguientes motivos:

Una falla temporal de la red
El servidor de backend está muy ocupado y no puede responder a las solicitudes durante un período temporal
El recurso de backend solicitado se puede haber quitado o no está disponible durante un período
El servidor de backend responde con lentitud debido al tiempo de procesamiento alto durante un período temporal, etc.

En todos estos casos, las fallas pueden ocurrir durante un período desconocido y, luego, podemos comenzar a obtener respuestas exitosas. Si almacenamos en caché las respuestas de error, es posible que sigamos enviando respuestas de error a los usuarios, incluso si el problema con el servidor de backend se solucionó.

Situación 2: Falla prolongada o fija de backend o recursos

Si sabemos que la falla en el backend durará un período de tiempo fijo. Por ejemplo, sabes que:

Un recurso de backend específico no estará disponible durante 1 hora
O
El servidor de backend se quita o no está disponible durante 24 horas debido a una falla repentina del sitio, problemas de escalamiento, mantenimiento, actualización, etcétera.

Con esta información, podemos establecer el tiempo de caducidad de la caché de manera adecuada en la política ResponseCache para que no almacenemos en caché las respuestas de error durante más tiempo. Sin embargo, una vez que el servidor o el recurso de backend esté disponible de nuevo, tendremos que modificar la política para evitar el almacenamiento en caché de las respuestas de error. Esto se debe a que, si hay una falla temporal o de uno fuera del servidor de backend, almacenaremos en caché la respuesta y tendremos el problema que se describió en la situación 1.

Impacto

Almacenar en caché las respuestas de error puede provocar que se envíen respuestas de error incluso después de que se haya resuelto el problema en el servidor de backend
Los usuarios pueden dedicar mucho esfuerzo a solucionar la causa de un problema sin saber que se genera por almacenar en caché las respuestas de error del servidor de backend.

Práctica recomendada

No almacenes las respuestas de error en la caché de respuestas. Asegúrate de que el elemento <ExcludeErrorResponse> esté configurado como true en la política ResponseCache para evitar que las respuestas de error se almacenen en caché, como se muestra en el siguiente fragmento de código. Con esta configuración, solo se almacenarán en caché las respuestas de los códigos de éxito predeterminados del 200 al 205 (a menos que se modifiquen los códigos de éxito).

<!-- /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>

Si tienes el requisito de almacenar en caché las respuestas de error por algún motivo específico, puedes determinar la duración máxima/exacta para la cual se observará el error (si es posible):
- Establece la fecha de vencimiento de forma adecuada para asegurarte de no almacenar en caché las respuestas de error por más tiempo que en el que se puede ver la falla.
- Usa la política ResponseCache para almacenar en caché las respuestas de error sin el elemento <ExcludeErrorResponse>.
Haz esto solo si estás completamente seguro de que la falla del servidor de backend no es por un período breve o temporal.
Apigee no recomienda almacenar en caché respuestas 5xx de servidores de backend.