# Arquitectura de la carga de trabajo
**Topics**
+ [REL 3 ¿Cómo diseña la arquitectura de servicio de su carga de trabajo?](w2aac19b9b7b5.md)
+ [REL 4 ¿Cómo diseña las interacciones en un sistema distribuido para evitar errores?](w2aac19b9b7b7.md)
+ [REL 5 ¿Cómo diseña las interacciones en un sistema distribuido para mitigar o tolerar errores?](w2aac19b9b7b9.md)
# REL 3 ¿Cómo diseña la arquitectura de servicio de su carga de trabajo?
Desarrolle cargas de trabajo escalables y fiables utilizando una arquitectura orientada a servicios (SOA) o una arquitectura de microservicios. La arquitectura orientada a servicios (SOA) es la práctica de hacer que los componentes de software se puedan reutilizar mediante interfaces de servicio. La arquitectura de microservicios va más allá, para hacer que los componentes sean más pequeños y sencillos.
**Topics**
+ [REL03-BP01 Elegir cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Facilitar contratos de servicio por cada API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Elegir cómo segmentar su carga de trabajo
La segmentación de la carga de trabajo es importante a la hora de determinar los requisitos de resiliencia de su aplicación. La arquitectura monolítica debe evitarse siempre que sea posible. En su lugar, considere detenidamente qué componentes de la aplicación pueden dividirse en microservicios. Según los requisitos de su aplicación, esto puede terminar siendo una combinación de una arquitectura orientada a servicios (SOA) con microservicios cuando sea posible. Las cargas de trabajo que son capaces de no tener estado son más capaces desplegarse como microservicios.
**Resultado deseado:** Las cargas de trabajo deben ser soportables, escalables y estar tan poco acopladas como sea posible.
A la hora de elegir cómo segmentar la carga de trabajo, hay que sopesar las ventajas frente a las complejidades. Lo que puede ser adecuado para un nuevo producto encaminado a su primer lanzamiento es diferente a lo que necesita una carga de trabajo creada para escalarse desde el principio. Al refactorizar un monolito existente, tendrá que considerar en qué medida soportará la aplicación una descomposición hacia la falta de estado. Dividir los servicios en partes más pequeñas permite que equipos pequeños y bien definidos los desarrollen y administren. No obstante, los servicios más pequeños pueden introducir complejidades que incluyen un aumento de la latencia, una depuración más compleja y un mayor lastre operativo.
**Patrones comunes de uso no recomendados:**
+ El [microservicio *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) es una situación en la que los componentes atómicos son tan interdependientes que el error de uno de ellos provoca un error mucho mayor, haciendo que los componentes sean tan rígidos y frágiles como un monolito.
**Beneficios de establecer esta práctica:**
+ Los segmentos más específicos conducen a una mayor agilidad, flexibilidad organizativa y escalabilidad.
+ Reducción del impacto de las interrupciones del servicio.
+ Los componentes de la aplicación pueden tener diferentes requisitos de disponibilidad, que pueden soportarse mediante una segmentación más atómica.
+ Responsabilidades bien definidas para los equipos que apoyan la carga de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
Seleccione el tipo de arquitectura en función de cómo va a segmentar su carga de trabajo. Seleccione una SOA o una arquitectura de microservicios (o, en algunos casos raros, una arquitectura monolítica). Incluso si decide empezar con una arquitectura monolítica, debe asegurarse de que sea modular y de que pueda evolucionar hacia SOA o microservicios de forma definitiva, a medida que su producto escala con la adopción por parte de los usuarios. La SOA y los microservicios ofrecen respectivamente una segmentación más pequeña, lo que resulta preferible como arquitectura moderna escalable y confiable, pero existen compensaciones a tener en cuenta, especialmente al desplegar una arquitectura de microservicios.
Una compensación principal es que se dispone de una arquitectura de informática distribuida que puede dificultar el cumplimiento de los requisitos de latencia del usuario y existe una complejidad adicional en la depuración y el rastreo de las interacciones del usuario. Puede utilizar AWS X-Ray para ayudarle a resolver este problema. Otro efecto que hay que tener en cuenta es el aumento de la complejidad operativa a medida que aumenta el número de aplicaciones que se administran, lo que requiere el despliegue de componentes con varias independencias.
![\[Diagrama que muestra una comparación entre las arquitecturas monolíticas, orientadas al servicio y de microservicios\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/monolith-soa-microservices-comparison.png)
## Pasos para la aplicación
+ Determine la arquitectura adecuada para refactorizar o desarrollar su aplicación. La SOA y los microservicios ofrecen respectivamente una segmentación más pequeña, lo que resulta preferible como arquitectura moderna escalable y confiable. La SOA puede ofrecer un término intermedio ideal para conseguir una segmentación más pequeña y, a la vez, evitar algunas de las complejidades de los microservicios. Para obtener más información, consulte [Microservice Trade-Offs (Compensaciones de microservicios)](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Si su carga de trabajo lo admite y su organización puede permitírselo, debería usar una arquitectura de microservicios para conseguir la mejor agilidad y fiabilidad. Para obtener más información, consulte [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Tenga en cuenta seguir el patrón de [*Strangler Fig* para](https://martinfowler.com/bliki/StranglerFigApplication.html) refactorizar un monolito en componentes más pequeños. Se trata de sustituir gradualmente componentes específicos de la aplicación por nuevas aplicaciones y servicios. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) actúa como punto de partida para la refactorización incremental. Para obtener más información, consulte [Seamlessly migrate on-premises legacy workloads using a strangler pattern (Migrar sin problemas las cargas de trabajo heredadas localmente utilizando un patrón estrangulador)](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ La implementación de microservicios puede requerir un mecanismo de detección de servicios para permitir que estos servicios distribuidos se comuniquen entre sí. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) se puede usar con arquitecturas orientadas a servicios para ofrecer una detección y un acceso confiable a los servicios. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) también puede utilizarse para la detección dinámica de servicios basada en DNS.
+ Si está migrando de un monolito a SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) puede ayudar a salvar la brecha como un bus de servicio cuando se rediseñan las aplicaciones heredadas en la nube.
+ Para los monolitos existentes con una única base de datos compartida, elija cómo reorganizar los datos en segmentos más pequeños. Puede ser por unidad de negocio, patrón de acceso o estructura de datos. En este punto del proceso de refactorización, debe elegir entre una base de datos de tipo relacional o no relacional (NoSQL). Para obtener más información, consulte [From SQL to NoSQL (De SQL a NoSQL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Nivel de esfuerzo para el plan de implementación:** Alto
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
**Documentos relacionados:**
+ [Amazon API Gateway: Configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [¿Qué es la arquitectura orientada a servicios?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs (Compensaciones de microservicios)](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)
+ [¿Qué es AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Ejemplos relacionados:**
+ [Taller de modernización de aplicaciones iterativas](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vídeos relacionados:**
+ [Delivering Excellence with Microservices on AWS (Proporcionar excelencia con microservicios en AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos
La arquitectura orientada a servicios (SOA) desarrolla servicios con funciones bien delineadas definidas por necesidades empresariales. Los microservicios utilizan modelos de dominios y un contexto limitado para aplicar una restricción de modo que cada servicio lleve a cabo solo una cosa. Al centrarse en funciones específicas, puede diferenciar los requisitos de fiabilidad de los distintos servicios y dirigir las inversiones con un mayor nivel de especificidad. Tener un problema empresarial conciso y un equipo pequeño asociado a cada servicio también facilita un escalado organizativo más sencillo.
A la hora de diseñar una arquitectura de microservicios, resulta útil utilizar un diseño basado en dominio (DDD) para modelar el problema empresarial utilizando entidades. Por ejemplo, para el sitio web de Amazon.com, entre las entidades podrían estar el paquete, la entrega, la programación, el precio, el descuento y la divisa. Posteriormente, el modelo se divide aún más en modelos más pequeños con un [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), en el que se agrupan las entidades que comparten características y atributos similares. Así, si usamos como ejemplo Amazon.com, el paquete, la entrega y la programación formarían parte del contexto de envío, y el precio, el descuento y la divisa formarían parte del contexto de precios. Si el modelo está dividido en contextos, aparecerá una plantilla para limitar los microservicios.
![\[Plantilla modelo para la limitación de microservicios\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/building-services.png)
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Diseñe su carga de trabajo en función de sus dominios empresariales y la funcionalidad correspondiente. Al centrarse en funciones específicas, puede diferenciar los requisitos de fiabilidad de los distintos servicios y dirigir las inversiones con un mayor nivel de especificidad. Tener un problema empresarial conciso y un equipo pequeño asociado a cada servicio también facilita un escalado organizativo más sencillo.
+ Lleve a cabo un análisis del dominio para trazar un diseño basado en dominio (DDD) para su carga de trabajo. Posteriormente, podrá elegir un tipo de arquitectura que se ajuste a las necesidades de su carga de trabajo.
+ [Cómo descomponer un sistema monolítico en microservicios](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Introducción al DDD en un ambiente lleno de sistemas heredados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Eric Evans «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Diseño basado en dominios: afrontar la complejidad en el corazón del software)](https://www.amazon.com/gp/product/0321125215)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Descomponga sus servicios en los componentes más pequeños posibles. Con la arquitectura de microservicios, puede separar su carga de trabajo en componentes con la funcionalidad mínima para permitir la escalabilidad y la agilidad organizativas.
+ Defina la API para la carga de trabajo y sus objetivos de diseño, límites y cualquier otra consideración de uso.
+ Defina la API.
+ La definición de la API debería permitir el crecimiento y la incorporación de parámetros adicionales.
+ Defina las disponibilidades diseñadas.
+ Su API puede tener múltiples objetivos de diseño para diferentes funciones.
+ Establezca límites
+ Utilice pruebas para definir los límites de sus capacidades de carga de trabajo.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: Configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Eric Evans «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Diseño basado en dominios: afrontar la complejidad en el corazón del software)](https://www.amazon.com/gp/product/0321125215)
+ [Introducción al DDD en un ambiente lleno de sistemas heredados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [Cómo descomponer un sistema monolítico en microservicios](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensaciones de los microservicios](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)
# REL03-BP03 Facilitar contratos de servicio por cada API
Los contratos de servicio son acuerdos documentados entre equipos sobre la integración de servicios e incluyen una definición de API legible por máquina, límites de tasa y expectativas de rendimiento. Una estrategia de control de versiones permite a los clientes seguir usando la API existente y migrar sus aplicaciones a la nueva API cuando estén listos. El despliegue puede ocurrir en cualquier momento siempre y cuando no se infrinja el contrato. El proveedor del servicio puede usar la pila tecnológica que prefiera para cumplir el contrato de la API. Del mismo modo, el consumidor del servicio puede usar su propia tecnología.
Los microservicios toman el concepto de arquitectura orientada a servicios (SOA) para crear servicios que tengan un conjunto mínimo de funcionalidades. Cada servicio publica una API y objetivos de diseño, límites y otras consideraciones para el uso del servicio. Esto establece un *contrato* con las aplicaciones de llamada. Con ello, se logran tres beneficios principales:
+ El servicio tiene un problema comercial conciso que atender y un pequeño equipo que tiene el problema comercial. Así, se permite un mejor escalado organizativo.
+ El equipo puede desplegar en cualquier momento siempre que se cumplan los requisitos de la API y del contrato.
+ El equipo puede usar cualquier pila tecnológica siempre que cumpla los requisitos de la API y del contrato.
Amazon API Gateway es un servicio completamente administrado que facilita que los desarrolladores creen, publiquen, mantengan, supervisen y protejan las API a cualquier escala. Gestiona todas las tareas involucradas en la aceptación y el procesamiento de cientos de miles de llamadas simultáneas a la API, lo que incluye la administración del tráfico, la autorización y el control de acceso, la supervisión y la administración de la versión de la API. Por medio de la especificación OpenAPI (OAS), conocida anteriormente como especificación Swagger, puede definir el contrato de API e importarlo a API Gateway. Con API Gateway, puede versionar y desplegar las API.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Bajo
## Guía para la implementación
+ Proporcione contratos de servicio por API. Los contratos de servicio son acuerdos documentados entre equipos sobre la integración de servicios e incluyen una definición de API legible por máquina, límites de tasa y expectativas de rendimiento.
+ [Amazon API Gateway: configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ Una estrategia de control de versiones permite a los clientes seguir usando la API existente y migrar sus aplicaciones a la nueva API cuando estén listos.
+ Amazon API Gateway es un servicio completamente administrado que facilita que los desarrolladores creen API a cualquier escala. Por medio de la especificación OpenAPI (OAS), conocida anteriormente como especificación Swagger, puede definir su contrato de API e importarlo a API Gateway. Con API Gateway, puede versionar y desplegar las API.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compensaciones de los microservicios](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)
# REL 4 ¿Cómo diseña las interacciones en un sistema distribuido para evitar 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 evitan que se produzcan errores y mejoran el tiempo medio entre errores (MTBF).
**Topics**
+ [REL04-BP01 Identificar qué tipo de sistema distribuido se necesita](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementar dependencias con acoplamiento flexible](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Realizar un trabajo constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Hacer que todas las respuestas sean idempotentes](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificar qué tipo de sistema distribuido se necesita
Los sistemas distribuidos en tiempo real estrictos requieren que las respuestas se proporcionen de forma sincrónica y rápidamente, mientras que los sistemas en tiempo real laxos cuentan con un plazo de tiempo más generoso, que se mide en minutos o más, para proporcionar una respuesta. Los sistemas sin conexión gestionan las respuestas a través del procesamiento por lotes o asincrónico. Los sistemas distribuidos en tiempo real estrictos tienen los requisitos de fiabilidad más exigentes.
Los desafíos más complicados [relacionados con los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) giran en torno a los sistemas distribuidos en tiempo real, conocidos también como servicios de solicitud/respuesta. Lo que hace que sean tan difíciles es que las solicitudes llegan de forma impredecible y las respuestas deben emitirse rápidamente (por ejemplo, si el cliente está esperando una respuesta de forma activa). Entre algunos ejemplos se incluyen los servidores web de front-end, la canalización de pedidos, las transacciones con tarjetas de crédito, todas las API de AWS y la telefonía.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Identifique qué tipo de sistema distribuido se necesita. Entre los problemas de los sistemas distribuidos se incluyen la latencia, el escalado, conocer las API de red, la serialización y deserialización de los datos, y la complejidad de algoritmos como Paxos. A medida que los sistemas crecen y se hacen más distribuidos, los casos extremos teóricos se convierten en sucesos habituales.
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ Los sistemas distribuidos en tiempo real estrictos requieren que las respuestas se proporcionen de forma sincrónica y rápidamente.
+ Los sistemas en tiempo real laxos cuentan con un plazo más generoso, que se mide en minutos o más, para proporcionar una respuesta.
+ Los sistemas sin conexión gestionan las respuestas a través del procesamiento por lotes o asincrónico.
+ Los sistemas distribuidos en tiempo real estrictos tienen los requisitos de fiabilidad más exigentes.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Videos relacionados:**
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Bucles cerrados y mentes abiertas: cómo asumir el control de los sistemas grandes y pequeños ARC337 (incluye acoplamiento flexible, trabajo constante y estabilidad estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Implementar dependencias con acoplamiento flexible
Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento flexible. El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
Si un cambio en un componente obliga a otros componentes que dependen de él a aplicar ese cambio, entonces los componentes tienen un *acoplamiento* estricto. *El acoplamiento* flexible elimina esta dependencia, de forma que los componentes dependientes solo necesitan conocer la nueva versión de la interfaz publicada. Al implementar un acoplamiento flexible entre dependencias, se aíslan los fallos que se puedan producir en una, de modo que no afecten a la otra.
El acoplamiento flexible le permite añadir código o funciones adicionales a un componente mientras se reduce al mínimo el riesgo para los componentes que dependen de él. Además, se mejora la escalabilidad, ya que puede escalar horizontalmente o incluso cambiar la implementación subyacente de la dependencia.
Para mejorar aún más la resiliencia mediante el acoplamiento flexible, haga que las interacciones entre componentes sean asíncronas siempre que sea posible. Este modelo es adecuado para cualquier interacción que no necesite una respuesta inmediata y en la que baste con el reconocimiento de que una solicitud se ha registrado. Consta de un componente que genera eventos y de otro que los consume. Ambos componentes no se integran mediante una interacción directa de punto a punto, sino que normalmente emplean una capa de almacenamiento duradera intermedia, como una cola SQS o una plataforma de retransmisión de datos como Amazon Kinesis o AWS Step Functions.
![\[Diagrama que muestra el acoplamiento flexible de dependencias como sistemas de colas y equilibradores de carga\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Las colas de Amazon SQS y los equilibradores de carga elásticos son solo dos formas de añadir una capa intermedia para el acoplamiento flexible. Las arquitecturas basadas en eventos también pueden integrarse en Nube de AWS utilizando Amazon EventBridge, lo que puede abstraer a los clientes (productores de eventos) de los servicios en los que confían (consumidores de eventos). Amazon Simple Notification Service (Amazon SNS) es una solución eficaz cuando se necesita una mensajería de alto rendimiento, basada en push y de varios a varios. Utilizando temas de Amazon SNS, los sistemas de tu publicador pueden repartir mensajes por una gran cantidad de puntos de conexión de suscriptores para su procesamiento paralelo.
Aunque las colas ofrecen varias ventajas, en la mayoría de sistemas inflexibles en tiempo real, las solicitudes que superan un umbral temporal (que suele ser de segundos) se consideran obsoletas (el cliente ha desistido y ya no espera una respuesta), por lo que no se procesan. De esta manera, se pueden procesar las solicitudes más recientes (y probablemente aún válidas) en su lugar.
**Patrones de uso no recomendados comunes:**
+ Implementar un singleton como parte de una carga de trabajo
+ Invocar directamente las API entre capas de la carga de trabajo sin la capacidad de conmutar por error ni procesar asincrónicamente la solicitud
**Beneficios de establecer esta práctica recomendada:** El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad. Un error en un componente está aislado de los demás componentes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Implementar dependencias con acoplamiento flexible Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento flexible. El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge le permite crear arquitecturas basadas en eventos, que tienen acoplamiento flexible y son arquitecturas distribuidas.
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Si un cambio en un componente obliga a otros componentes que dependen de él a aplicar ese cambio, entonces los componentes tienen un acoplamiento estricto. El acoplamiento flexible elimina esta dependencia, de forma que los componentes dependientes solo necesitan conocer la nueva versión de la interfaz publicada.
+ Haga que las interacciones de los componentes sean asincrónicas siempre que sea posible. Este modelo es adecuado para cualquier interacción que no necesite una respuesta inmediata y en la que baste con el reconocimiento de que una solicitud se ha registrado.
+ [AWS re:Invent 2019: Aplicaciones escalables basadas en eventos sin servidor mediante Amazon SQS y Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
## Recursos
**Documentos relacionados:**
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vídeos relacionados:**
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Bucles cerrados y mentes abiertas: cómo asumir el control de los sistemas grandes y pequeños ARC337 (incluye acoplamiento flexible, trabajo constante y estabilidad estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Aplicaciones escalables basadas en eventos sin servidor mediante Amazon SQS y Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Realizar un trabajo constante
Los sistemas pueden producir error cuando hay cambios rápidos grandes en la carga. Por ejemplo, si la carga de trabajo está realizando una comprobación de estado que supervisa el estado de miles de servidores, debería enviar siempre una carga del mismo tamaño (una instantánea completa del estado actual). Si no hay errores en ningún servidor, o hay errores en todos ellos, el sistema de comprobación de estado estará haciendo un trabajo constante sin rápidos cambios de gran tamaño.
Por ejemplo, si el sistema de comprobación de estado supervisa 100 000 servidores, la carga contenida en él es nominal con un porcentaje de errores del servidor normalmente bajo. Sin embargo, si un evento importante deja a la mitad de esos servidores en mal estado, el sistema de comprobación de estado se sobrecargaría intentando actualizar los sistemas de notificación y comunicar el estado a sus clientes. Por ello, el sistema de comprobación de estado debería enviar cada vez la instantánea completa del estado actual. 100 000 estados de servidor, cada uno representado por un bit, solo constituiría una carga de 12,5 KB. Si no hay errores en ningún servidor, o hay errores en todos ellos, el sistema de comprobación de estado estará haciendo un trabajo constante y los cambios rápidos de gran tamaño no pondrán en peligro la estabilidad del sistema. En realidad, así es como Amazon Route 53 gestiona las comprobaciones de estado de los puntos de conexión (como las direcciones IP) para determinar cómo se enruta a los usuarios finales.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Bajo
## Guía para la implementación
+ Realice un trabajo para que los sistemas no tengan errores cuando hay cambios grandes y rápidos en la carga.
+ Implemente dependencias con acoplamiento flexible. Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento flexible. El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work) (Cerrar los bucles y abrir las mentes: cómo tomar el control de los sistemas, grandes y pequeños ARC337 [incluye trabajo constante])](https://youtu.be/O8xLxNje30M?t=2482)
+ En el ejemplo de una sistema de comprobación de estado que supervisa 100 000 servidores, diseñe las cargas de trabajo de forma que los tamaños de la carga útil sean iguales independientemente del número de éxitos o fracasos.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (Introducción a las arquitecturas basadas en eventos y Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work) (Cerrar los bucles y abrir las mentes: cómo asumir el control de los sistemas grandes y pequeños ARC337 [incluye trabajo constante])](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability) (Cerrar los bucles y abrir las mentes: cómo asumir el control de los sistemas grandes y pequeños ARC337 [incluye acoplamiento flexible, trabajo constante y estabilidad estática])](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (Optar por arquitecturas basadas en eventos) (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Hacer que todas las respuestas sean idempotentes
Un servicio idempotente promete que cada solicitud se completará una y solo una vez, de tal forma que realizar varias solicitudes idénticas tiene el mismo efecto que realizar una sola solicitud. Un servicio idempotente permite que un cliente implemente fácilmente los reintentos sin el temor de que una solicitud se procese erróneamente varias veces. Para ello, los clientes pueden usar solicitudes de API con un token de idempotencia: se utiliza el mismo token siempre que se repite la solicitud. Una API de servicio idempotente usa el token para devolver una respuesta idéntica a la que se devolvió por primera vez cuando se completó la solicitud.
En un sistema distribuido, es fácil llevar a cabo una acción una vez como máximo (el cliente realiza solo una solicitud) o al menos una vez (sigue realizando la solicitud hasta que el cliente obtiene una confirmación del éxito). Sin embargo, es difícil garantizar que una acción es idempotente, lo que significa que se lleva a cabo *exactamente* una vez, de modo que realizar varias solicitudes idénticas tiene el mismo efecto que realizar una sola solicitud. Al usar tokens de idempotencia en las API, los servicios pueden recibir una solicitud de migración una o más veces sin crear registros duplicados ni efectos secundarios.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Haga que todas las respuestas sean idempotentes. Un servicio idempotente promete que cada solicitud se completará una y solo una vez, de tal forma que realizar varias solicitudes idénticas tiene el mismo efecto que realizar una sola solicitud.
+ Los clientes pueden usar solicitudes de API con un token de idempotencia: se utiliza el mismo token siempre que se repite la solicitud. Una API de servicio idempotente usa el token para devolver una respuesta idéntica a la que se devolvió por primera vez cuando se completó la solicitud.
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Videos relacionados:**
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Bucles cerrados y mentes abiertas: cómo asumir el control de los sistemas grandes y pequeños ARC337 (incluye acoplamiento flexible, trabajo constante y estabilidad estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://youtu.be/h46IquqjF3E)
# 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