# REL 5 ¿Cómo diseña las interacciones en un sistema distribuido para mitigar o tolerar errores?
Los sistemas distribuidos dependen de las redes de comunicaciones para interconectar componentes, como servidores o servicios. Su carga de trabajo debe funcionar de manera fiable aunque se pierdan datos o haya latencia en estas redes. Los componentes del sistema distribuido deben funcionar de forma que no repercutan negativamente en otros componentes ni en la carga de trabajo. Estas prácticas recomendadas permiten que las cargas de trabajo toleren el estrés o los errores, se recuperen más rápidamente de ellos y mitiguen el impacto de dichos errores. El resultado es un tiempo medio de recuperación (MTTR) mejor.
**Topics**
+ [REL05-BP01 Implementar una degradación estable para transformar las dependencias estrictas en flexibles](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Limitar las solicitudes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controlar y limitar las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Responder rápido a los errores y limitar las colas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definir tiempos de espera del cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Crear servicios sin estado cuando sea posible](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementar recursos de emergencia](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementar una degradación estable para transformar las dependencias estrictas en flexibles
Cuando las dependencias de un componente no están en buen estado, el propio componente puede seguir funcionando, aunque con la capacidad mermada. Por ejemplo, cuando se produzca un error en una llamada a una dependencia, conmute por error a una respuesta estática predeterminada.
Considere un servicio B que lo llama el servicio A y que a su vez llama al servicio C.
![\[Diagrama que muestra que se produce un error en el servicio C cuando se le llama desde el servicio B. El servicio B devuelve una respuesta degradada al servicio A\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Cuando el servicio B llama al servicio C, recibe un error o un tiempo de espera agotado. El servicio B, a falta de una respuesta del servicio C (y de los datos que contiene), devuelve lo que puede. Este puede ser el último valor bueno almacenado en caché, o el servicio B puede sustituir una respuesta estática predeterminada por la que habría recibido del servicio C. A continuación, puede devolver una respuesta degradada al autor de la llamada, el servicio A. Sin esta respuesta estática, el error en el servicio C se transmitiría en cascada a través del servicio B al servicio A, lo que provocaría una pérdida de disponibilidad.
Según el factor multiplicativo en la ecuación de disponibilidad para las dependencias estrictas (consulte [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), cualquier caída en la disponibilidad de C repercute gravemente en la disponibilidad efectiva de B. Al devolver la respuesta estática, el servicio B mitiga el error en C y, aunque degradado, hace que la disponibilidad del servicio C parezca del 100 % (suponiendo que devuelva la respuesta estática de forma fiable en condiciones de error). Tenga en cuenta que la respuesta estática es una simple alternativa a la devolución de un error y no es un intento de volver a calcular la respuesta con otros medios. Estos intentos de utilizar un mecanismo completamente diferente para tratar de conseguir el mismo resultado se denominan comportamientos alternativos y son un patrón de uso no recomendado que debe evitarse.
Otro ejemplo de degradación correcta es el *patrón de disyuntor*. Las estrategias de reintentos deben utilizarse cuando el error es transitorio. Cuando no es así, y es probable que la operación tenga un error, el patrón de disyuntor evita que el cliente realice una solicitud que probablemente falle. Cuando las solicitudes se procesan normalmente, el interruptor se cierra y las solicitudes fluyen. Cuando el sistema remoto comienza a devolver errores o presenta una alta latencia, el disyuntor se abre y se ignora la dependencia o se reemplazan los resultados por respuestas más sencillas pero menos completas (que podrían ser simplemente una caché de respuestas). Periódicamente, el sistema intenta llamar a la dependencia para determinar si se ha recuperado. Cuando eso ocurre, el interruptor se cierra.
![\[Diagrama que muestra el disyuntor en estado abierto y cerrado.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Además de los estados cerrado y abierto mostrados en el diagrama, tras un periodo de tiempo configurable en el estado abierto, el disyuntor puede cambiar a semiabierto. En este estado, intenta llamar periódicamente al servicio a un ritmo mucho más bajo de lo normal. Este sondeo se utiliza para comprobar el estado del servicio. Después de una serie de éxitos en el estado semiabierto, el disyuntor pasa al estado cerrado y se reanudan las solicitudes normales.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Implemente una degradación estable para transformar las dependencias estrictas en flexibles. Cuando las dependencias de un componente no están en buen estado, el propio componente puede seguir funcionando, aunque con la capacidad mermada. Por ejemplo, cuando se produzca un error en una llamada a una dependencia, conmute por error a una respuesta estática predeterminada.
+ Al devolver una respuesta estática, la carga de trabajo mitiga los errores que se producen en sus dependencias.
+ [Laboratorio de Well-Architected: Nivel 300: Implementación de comprobaciones de estado y administración de dependencias para mejorar la fiabilidad](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ Detecte cuándo es probable que la operación de reintento produzca un error e impedir que el cliente realice llamadas infructuosas con el patrón de disyuntor.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: Limitar las solicitudes de la API para mejorar el rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (resumen del patrón de interruptor del libro «Release It\$1»)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Error Retries and Exponential Backoff in AWS (Reintentos en caso de error y retroceso exponencial en AWS)](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard «Release It\$1 Design and Deploy Production-Ready Software»](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Reintento, retroceso y alteración: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (Presentación de Amazon Builders’ Library) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Ejemplos relacionados:**
+ [Laboratorio de Well-Architected: Nivel 300: Implementación de comprobaciones de estado y administración de dependencias para mejorar la fiabilidad](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 Limitar las solicitudes
La limitación de solicitudes es un patrón de mitigación para responder a un aumento imprevisto de la demanda. Algunas solicitudes se aceptan, pero aquellas que sobrepasan un límite definido se rechazan y se devuelve un mensaje en el que se indica que se han restringido. Lo que se espera de los clientes es que abandonen la solicitud o la repitan con una frecuencia menor.
Los servicios se deben diseñar para administrar una capacidad conocida de solicitudes que cada nodo o celda pueda procesar. Esta capacidad se puede establecer mediante pruebas de carga. A continuación, es necesario hacer un seguimiento de la tasa de llegada de las solicitudes y si la tasa de llegada temporal supera este límite, la respuesta adecuada es señalar que se ha limitado la solicitud. Esto permite al usuario realizar un reintento, potencialmente en un nodo o celda que pueda tener capacidad disponible. Amazon API Gateway proporciona métodos para limitar las solicitudes. Amazon SQS y Amazon Kinesis pueden guardar las solicitudes en búfer, suavizar la tasa de solicitudes y aliviar la necesidad de limitar aquellas solicitudes que puedan atenderse de forma asíncrona.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Limite las solicitudes. Este es un patrón de mitigación para responder a un aumento imprevisto de la demanda. Algunas solicitudes se aceptan, pero aquellas que sobrepasan un límite definido se rechazan y se devuelve un mensaje en el que se indica que se han restringido. Lo que se espera de los clientes es que abandonen la solicitud o la repitan con una frecuencia menor.
+ Use Amazon API Gateway
+ [Limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Reintentos en caso de error y retroceso exponencial en AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Vídeos relacionados:**
+ [Reintento, retroceso y fluctuación: AWS re:Invent 2019: presentación de la Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Controlar y limitar las llamadas de reintento
Use el retroceso exponencial para los reintentos tras intervalos cada vez más largos. Introduzca una fluctuación para asignar un orden aleatorio a estos intervalos de reintento y limite el número máximo de reintentos.
Entre los componentes típicos de un sistema de software distribuido se incluyen servidores, equilibradores de carga, bases de datos y servidores DNS. Durante la operación, y sujetos a fallos, cualquiera de estos componentes pueden generar errores. La técnica predeterminada para corregir estos errores es implementar reintentos en el lado del cliente. Esta técnica aumenta la fiabilidad y disponibilidad de la aplicación. Sin embargo, a escala (y si los clientes intentan reintentar la operación fallida en cuanto se produce un error), la red puede saturarse rápidamente con solicitudes nuevas y reintentadas, ya que todas compiten por el mismo ancho de banda de la red. Esto puede dar como resultado una *tormenta de reintentos,* que reducirá la disponibilidad del servicio. Este patrón podría continuar hasta que se produzca un fallo total del sistema.
Para evitar este tipo de escenarios, deben usarse algoritmos de retroceso, como los de *retroceso exponencial* que se utilizan habitualmente. Los algoritmos de retroceso exponencial reducen gradualmente el ritmo al que se realizan los reintentos, evitando así la congestión de la red.
Muchos SDK y bibliotecas de software, incluidas las de AWS, implementan una versión de estos algoritmos. Sin embargo, **no dé nunca por sentado que ya existe un algoritmo de retroceso: compruébelo siempre y verifique si se da el caso.**
El retroceso por sí solo no es suficiente, ya que en sistemas distribuidos, todos los clientes podrían retroceder simultáneamente, creando clústeres de llamadas de reintento. Marc Brooker, en su publicación de blog [Exponential backoff and jitter (Retroceso exponencial y fluctuación)](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), explica cómo modificar la función wait() en el retroceso exponencial para evitar clústeres de llamadas de reintento. La solución es añadir *fluctuación* en la función wait(). Para evitar que los reintentos se prolonguen demasiado tiempo, las implementaciones deberían restringir el retroceso a un valor máximo.
Por último, es importante configurar un *número máximo de reintentos* o un máximo de tiempo, transcurrido el cual los reintentos fallarán. Los SDK de AWS implementan esto de forma predeterminada y permiten configurarlo. Para servicios que se encuentren más abajo en la pila, un límite de reintentos máximo de cero o uno puede limitar el riesgo y, aun así, ser eficaz, ya que los reintentos se delegan a servicios que ocupan puestos más altos en la pila.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Controle y limite las llamadas de reintento. Use el retroceso exponencial para los reintentos tras intervalos cada vez más largos. Introduzca una fluctuación para asignar un orden aleatorio a estos intervalos de reintento y limite el número máximo de reintentos.
+ [Reintentos en caso de error y retroceso exponencial en AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Los SDK de Amazon implementan los reintentos y el retroceso exponencial de forma predeterminada. Implemente una lógica similar en su capa de dependencia a la hora de llamar a sus propios servicios dependientes. Decida cuáles son los tiempos de espera y cuándo dejar de reintentar según su caso de uso.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Reintentos en caso de error y retroceso exponencial en AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Reintento, retroceso y alteración: AWS re:Invent 2019: Presentación de Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Responder rápido a los errores y limitar las colas
Si la carga de trabajo no puede ofrecer una respuesta correcta a una solicitud, debe producir un error rápidamente. Esto permite que se liberen recursos asociados con solicitudes y que un servicio se recupere cuando se le agotan los recursos. Si la carga de trabajo puede proporcionar una respuesta adecuada, pero la tasa de solicitudes es demasiado alta, use una cola para almacenar las solicitudes en un búfer. Sin embargo, no permita que por el hecho de que existan colas grandes se atiendan solicitudes antiguas que el cliente ya ha abandonado.
Esta práctica recomendada se aplica al servidor, o receptor de la solicitud.
Tenga en cuenta que las colas de espera se pueden crear en varios niveles de un sistema y que pueden obstaculizar gravemente la capacidad de recuperación rápida, ya que las solicitudes antiguas (que ya no necesitan una respuesta) se procesan antes que las nuevas. Tenga en cuenta en qué ubicaciones están las colas. A menudo se encuentran en los flujos de trabajo o en trabajos que se registran en una base de datos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Responda rápido a los errores y limite las colas. Si la carga de trabajo no puede ofrecer una respuesta correcta a una solicitud, debe producir un error rápidamente. Esto permite que se liberen recursos asociados con solicitudes y que un servicio se recupere cuando se le agotan los recursos. Si la carga de trabajo puede proporcionar una respuesta adecuada, pero la tasa de solicitudes es demasiado alta, use una cola para almacenar las solicitudes en un búfer. Sin embargo, no permita que por el hecho de que existan colas grandes se atiendan solicitudes antiguas que el cliente ya ha abandonado.
+ Implemente una respuesta rápida a los errores cuando el servicio está bajo presión.
+ [Respuesta rápida a errores](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Limite las colas: en un sistema basado en colas, cuando se detiene el procesamiento pero siguen llegando mensajes, los mensajes pendientes pueden seguir acumulándose en un depósito grande de trabajos pendientes, lo que aumenta el tiempo de procesamiento. El trabajo se puede completar demasiado tarde para que los resultados sean útiles, lo que afectaría a la disponibilidad, que es justo lo que se suponía que las colas deberían proteger.
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Recursos
**Documentos relacionados:**
+ [Error Retries and Exponential Backoff in AWS (Reintentos en caso de error y retroceso exponencial en AWS)](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Respuesta rápida a errores](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Reintento, retroceso y alteración: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (Presentación de Amazon Builders’ Library) (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Definir tiempos de espera del cliente
Defina tiempos de espera apropiados, verifíquelos sistemáticamente y no use los valores predeterminados, ya que suelen ser demasiado altos
Esta práctica recomendada se aplica al lado del cliente o emisor de la solicitud.
Defina un tiempo de espera de conexión y un tiempo de espera de solicitud en todas las llamadas remotas y, normalmente, en todas las llamadas de los procesos. Muchos marcos ofrecen funciones de tiempo de espera integradas, pero use estas funciones con precaución ya que muchas tienen valores predeterminados que son infinitos o demasiado altos. Un valor demasiado alto reduce la utilidad del tiempo de espera porque se siguen consumiendo recursos mientras el cliente espera a que transcurra el tiempo de espera. Un valor demasiado bajo puede generar un aumento del tráfico en el backend y un aumento de la latencia debido a demasiados reintentos de las solicitudes. En algunos casos, esto puede producir una interrupción completa si se reintentan todas las solicitudes.
Para obtener más información sobre cómo Amazon usa los tiempos de espera, los reintentos y el retardo con fluctuación, consulte [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Defina un tiempo de espera de conexión y un tiempo de espera de solicitud en todas las llamadas remotas y, normalmente, en todas las llamadas de los procesos. Muchos marcos ofrecen funciones de tiempo de espera integradas, pero use estas funciones con precaución ya que muchas tienen valores predeterminados que son infinitos o demasiado altos. Un valor demasiado alto reduce la utilidad del tiempo de espera porque se siguen consumiendo recursos mientras el cliente espera a que transcurra el tiempo de espera. Un valor demasiado bajo puede generar un aumento del tráfico en el backend y un aumento de la latencia debido a demasiados reintentos de las solicitudes. En algunos casos, esto puede producir una interrupción completa si se reintentan todas las solicitudes.
+ [SDK de AWS: reintentos y tiempos de espera](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Recursos
**Documentos relacionados:**
+ [SDK de AWS: reintentos y tiempos de espera](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: limitar las solicitudes de API para un mayor rendimiento](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Reintentos en caso de error y retroceso exponencial en AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [La Amazon Builders' Library: Tiempos de espera, reintentos y retroceso con alteración](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Reintento, retroceso y alteración: AWS re:Invent 2019: Presentación de Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Crear servicios sin estado cuando sea posible
Los servicios deben o bien no requerir estado o bien descargar el estado, de forma que entre solicitudes de clientes distintos no haya dependencia en los datos almacenados localmente en disco y en memoria. Esto permite reemplazar los servidores a voluntad sin que la disponibilidad resulte afectada. Amazon ElastiCache y Amazon DynamoDB son buenos destinos para el estado descargado.
![\[En esta aplicación web sin estado, el estado de la sesión se descarga en Amazon ElastiCache.\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Cuando los usuarios o los servicios interactúan con una aplicación, suelen realizar una serie de interacciones que constituyen una sesión. Una sesión es un dato único para los usuarios que persiste entre las solicitudes mientras utilizan la aplicación. Una aplicación sin estado es aquella que no necesita conocer las interacciones anteriores y no almacena la información de la sesión.
Una vez se ha diseñado para no tener estado, puede utilizar servicios de computación sin servidor, como AWS Lambda o AWS Fargate.
Además del reemplazo del servidor, otro beneficio de las aplicaciones sin estado es que pueden escalar horizontalmente porque cualquiera de los recursos de computación disponibles (como las instancias EC2 y funciones AWS Lambda) puede dar servicio a cualquier solicitud.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Haga que sus aplicaciones no tengan estado. Las aplicaciones sin estado permiten el escalado horizontal y toleran el error de un nodo individual.
+ Elimine el estado que realmente podría almacenarse en parámetros de solicitud.
+ Tras examinar si el estado es realmente necesario, mueva cualquier seguimiento de estado a una caché o un almacén de datos resilientes de varias zonas como Amazon ElastiCache, Amazon RDS, Amazon DynamoDB o una solución de datos distribuidos de terceros. Almacene el estado que no se pudo mover a almacenes de datos resilientes.
+ Algunos datos (como las cookies) se pueden pasar a encabezados o parámetros de consulta.
+ Refactorice para eliminar el estado que se puede pasar rápidamente a las solicitudes.
+ Algunos datos pueden no resultar realmente necesarios para la solicitud y pueden recuperarse bajo demanda.
+ Elimine los datos que se puedan recuperar asincrónicamente.
+ Elija un almacén de datos que cumpla los requisitos para el estado requerido.
+ Considere la posibilidad de usar una base de datos NoSQL para datos no relacionales.
## Recursos
**Documentos relacionados:**
+ [La Amazon Builders' Library: Evitar el retroceso en sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [La Amazon Builders' Library: Evitar trabajos pendientes en colas insalvables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [La Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Implementar recursos de emergencia
Los recursos de emergencia son procesos rápidos que pueden mitigar el impacto en la disponibilidad en su carga de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Implemente recursos de emergencia. Se trata de procesos rápidos que pueden mitigar el impacto en la disponibilidad de su carga de trabajo. Se pueden operar en ausencia de una causa raíz. Un recurso de emergencia ideal reduciría la carga cognitiva de las personas encargadas de la resolución a cero al proporcionar criterios de activación y desactivación totalmente deterministas. Estos recursos de emergencia suelen ser manuales, pero también se pueden automatizar.
+ Entre los recursos de emergencia se incluyen:
+ Bloqueo de todo el tráfico robótico
+ Presentación de páginas estáticas en lugar de páginas dinámicas
+ Reducción de la frecuencia de llamadas a una dependencia
+ Limitación de llamadas desde dependencias
+ Consejos para implementar y usar recursos de emergencia
+ Al activar los recursos de emergencia, trabaje MENOS, no más.
+ Cree recursos sencillos y evite el comportamiento bimodal.
+ Pruébelos periódicamente.
+ Estos son ejemplos de acciones que NO son recursos de emergencia.
+ Añadir capacidad
+ Llamar a los propietarios de servicio que dependen del servicio y pedirles que reduzcan las llamadas
+ Realizar un cambio en el código y publicarlo