Antipatrón: respuestas de error de caché

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

El almacenamiento en caché es un proceso que consiste en almacenar datos de forma temporal en un área de almacenamiento llamada caché para futuras consultas. El almacenamiento en caché de datos ofrece ventajas significativas en cuanto al rendimiento, ya que:

  • Permite recuperar datos más rápido.
  • Reduce el tiempo de procesamiento, ya que evita que los datos se regeneren una y otra vez.
  • Evita que las solicitudes de API lleguen a los servidores backend y, por lo tanto, reduce la carga de los servidores backend.
  • Permite un mejor uso de los recursos del sistema o de la aplicación.
  • Mejora los tiempos de respuesta de las APIs

Siempre que tengamos que acceder con frecuencia a datos que no cambian demasiado, te recomendamos que uses una caché para almacenarlos.

Apigee ofrece la posibilidad de almacenar datos en una caché en tiempo de ejecución para que persistan y se puedan recuperar más rápido. La función de almacenamiento en caché está disponible a través de las políticas PopulateCache, LookupCache, InvalidateCache y ResponseCache.

En esta sección, vamos a ver la política de caché de respuestas. La política de caché de respuestas de la plataforma Apigee te permite almacenar en caché las respuestas de los servidores backend. Si las aplicaciones cliente hacen solicitudes al mismo recurso de backend repetidamente y el recurso se actualiza periódicamente, podemos almacenar en caché estas respuestas mediante esta política. La política de caché de respuestas ayuda a devolver las respuestas almacenadas en caché y, por lo tanto, evita reenviar las solicitudes a los servidores backend innecesariamente.

La política de caché de respuestas:

  • Reduce el número de solicitudes que llegan al backend.
  • Reduce el ancho de banda de la red
  • Mejora el rendimiento de la API y los tiempos de respuesta

Antipatrón

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

A continuación, se muestra un ejemplo de política de caché de respuestas 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 de caché de respuestas almacena en caché las respuestas de error en su configuración predeterminada. Sin embargo, no es recomendable almacenar en caché las respuestas de error sin reflexionar detenidamente sobre las implicaciones negativas, ya que:

  • Situación 1: Se producen errores durante un periodo temporal desconocido y es posible que sigamos enviando respuestas de error debido al almacenamiento en caché incluso después de que se haya solucionado el problema.

    OR

  • Situación 2: Se observarán errores durante un periodo fijo. Después, tendremos que modificar el código para evitar que se almacenen en caché las respuestas una vez que se haya solucionado el problema.

Para explicarlo, vamos a analizar estos dos casos con más detalle.

Situación 1: Fallo temporal del backend o de los recursos

Ten en cuenta que el fallo del servidor backend se debe a uno de los siguientes motivos:

  • Un fallo de red temporal
  • El servidor backend está muy ocupado y no puede responder a las solicitudes durante un periodo temporal.
  • Es posible que el recurso de backend solicitado se haya quitado o no esté disponible durante un periodo temporal.
  • El servidor backend responde lentamente debido a un tiempo de procesamiento elevado durante un periodo temporal, etc.

En todos estos casos, los errores podrían producirse durante un periodo desconocido y, después, podríamos empezar a recibir respuestas correctas. Si almacenamos en caché las respuestas de error, es posible que sigamos enviando respuestas de error a los usuarios aunque se haya solucionado el problema con el servidor backend.

Situación 2: Fallo prolongado o fijo del backend o de los recursos

Supongamos que sabemos que el fallo en el backend se produce durante un periodo de tiempo fijo. Por ejemplo, sabes que se da una de las siguientes situaciones:

  • Un recurso de backend específico no estará disponible durante 1 hora.

    OR

  • El servidor backend se ha retirado o no está disponible durante 24 horas debido a un fallo repentino del sitio, problemas de escalado, tareas de mantenimiento, una actualización, etc.

Con esta información, podemos definir el tiempo de caducidad de la caché de forma adecuada en la política de caché de respuestas para no almacenar en caché las respuestas de error durante más tiempo. Sin embargo, cuando el servidor o el recurso backend vuelvan a estar disponibles, tendremos que modificar la política para evitar que se almacenen en caché las respuestas de error. Esto se debe a que, si se produce un error temporal o puntual en el servidor backend, almacenaremos en caché la respuesta y se producirá el problema que se explica en el caso 1 anterior.

Impacto

  • Si se almacenan en caché las respuestas de error, se pueden enviar respuestas de error incluso después de que se haya resuelto el problema en el servidor backend.
  • Los usuarios pueden dedicar mucho tiempo a solucionar la causa de un problema sin saber que se debe a que se almacenan en caché las respuestas de error del servidor backend.

Práctica recomendada

  • No almacenes las respuestas de error en la caché de respuestas. Asegúrate de que el elemento <ExcludeErrorResponse> tenga el valor true en la política ResponseCache para evitar que las respuestas de error se almacenen en caché, tal 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 necesitas almacenar en caché las respuestas de error por algún motivo específico, puedes determinar la duración máxima o exacta durante la que se observará el fallo (si es posible):
    • Define el tiempo de vencimiento adecuado para asegurarte de que no se almacenan en caché las respuestas de error durante más tiempo del que se puede ver el fallo.
    • Usa la política ResponseCache para almacenar en caché las respuestas de error sin el elemento <ExcludeErrorResponse>.

    Hazlo solo si tienes la certeza de que el fallo del servidor backend no es temporal.

  • Apigee no recomienda almacenar en caché las respuestas 5xx de los servidores backend.