# Arquitectura de la carga de trabajo
Una carga de trabajo fiable comienza por tomar decisiones de diseño anticipadas tanto para el software como para la infraestructura. Sus elecciones respecto a la arquitectura afectarán al comportamiento de su carga de trabajo en los seis pilares de Well-Architected. Para la fiabilidad, debe seguir patrones específicos.
En las siguientes secciones se explican las prácticas recomendadas que se pueden utilizar con estos patrones para garantizar la fiabilidad.
**Topics**
+ [Diseño de la arquitectura de servicio de su carga de trabajo](design-your-workload-service-architecture.md)
+ [Diseño de las interacciones en un sistema distribuido para evitar los errores](design-interactions-in-a-distributed-system-to-prevent-failures.md)
+ [Diseño de interacciones en un sistema distribuido para mitigar o tolerar errores](design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.md)
# Diseño de la arquitectura de servicio de su carga de trabajo
Desarrolle cargas de trabajo escalables y fiables mediante una arquitectura orientada a servicios (SOA) o una arquitectura de microservicios. La arquitectura orientada a servicios (SOA) es 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.
Las interfaces de arquitectura orientada a servicios (SOA) utilizan estándares de comunicación comunes para que puedan incorporarse rápidamente a las nuevas cargas de trabajo. La SOA sustituyó a la práctica de crear arquitecturas monolíticas, que consistían en unidades indivisibles e interdependientes.
En AWS, siempre hemos utilizado SOA, pero ahora hemos optado por crear nuestros sistemas mediante microservicios. Si bien los microservicios tienen varias cualidades atractivas, el beneficio más importante para la disponibilidad es que estos son más pequeños y sencillos. Permiten diferenciar la disponibilidad requerida de diferentes servicios y, por lo tanto, centrar las inversiones más específicamente en los microservicios que tienen mayores necesidades de disponibilidad. Por ejemplo, para entregar páginas de información de productos en Amazon.com (“páginas de detalles”), se invocan cientos de microservicios para crear porciones discretas de la página. Si bien hay algunos servicios que deben estar disponibles para proporcionar el precio y los detalles del producto, la gran mayoría del contenido de la página puede simplemente excluirse si el servicio no está disponible. Incluso las fotos y las reseñas no son necesarias para proporcionar una experiencia en la que un cliente pueda comprar un producto.
**Topics**
+ [REL03-BP01 Elección de cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Desarrollo de servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Disposición de contratos de servicio por cada API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Elección de 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 de implementarse como microservicios.
**Resultado deseado:** las cargas de trabajo se deben admitir, ser escalables y tener el acoplamiento más débil que 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:**
+ La [*Estrella de la muerte* de microservicios](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, lo que hace 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 fiable, pero existen compensaciones a tener en cuenta, especialmente al implementar una arquitectura de microservicios.
Una compensación principal es que se dispone de una arquitectura de computación 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 la implementación 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/latest/reliability-pillar/images/monolith-soa-microservices-comparison.png)
## Pasos para la implementació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 fiable. 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](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 [Implementing Microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html).
+ Considere la posibilidad de seguir el [patrón del *higo estrangulador*](https://martinfowler.com/bliki/StranglerFigApplication.html) para refactorizar un monolito en componentes más pequeños. Esto implica reemplazar 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](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ La implementación de microservicios puede necesitar de un mecanismo de detección de servicios que permita 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 utilizar con arquitecturas orientadas a los servicios para proporcionar una detección y un acceso fiables a estos. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) también se puede utilizar para la detección dinámica de servicios basada en DNS.
+ Si va a migrar de un entorno monolítico a SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) puede ayudarle a cerrar la brecha, en calidad de bus de servicio, a la hora de rediseñar 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](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 Desarrollo de servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
**Documentos relacionados:**
+ [Amazon API Gateway: Configuring a REST API Using OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [¿Qué es la arquitectura orientada a servicios (SOA)?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (a central pattern in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementing Microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](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:**
+ [Iterative App Modernization Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Videos relacionados:**
+ [Delivering Excellence with Microservices on AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Desarrollo de servicios centrados en funcionalidades y dominios empresariales específicos
La arquitectura orientada a servicios (SOA) define servicios con funciones bien delineadas y determinadas por necesidades empresariales. Los microservicios utilizan modelos de dominio y contextos delimitados para trazar los límites de los servicios en los límites del contexto empresarial. Centrarse en los dominios y las funcionalidades empresariales ayuda a los equipos a definir requisitos de fiabilidad independientes para sus servicios. Los contextos delimitados aíslan y encapsulan la lógica empresarial, lo que permite a los equipos mejorar la forma en que gestionan los errores.
**Resultado deseado:** los ingenieros y las partes interesadas de la empresa definen conjuntamente los contextos delimitados y los utilizan para diseñar sistemas como servicios que cumplan funciones empresariales específicas. Estos equipos utilizan prácticas establecidas, como las tormentas de eventos, para definir los requisitos. Las nuevas aplicaciones se diseñan como límites bien definidos de servicios y con acoplamiento débil. Los monolitos existentes se descomponen en [contextos delimitados](https://martinfowler.com/bliki/BoundedContext.html) y los diseños de sistemas avanzan hacia arquitecturas SOA o de microservicios. Cuando los monolitos se refactorizan, se aplican enfoques establecidos, como contextos burbuja y patrones de descomposición de monolitos.
Los servicios orientados al dominio se ejecutan como uno o más procesos que no comparten el estado. Responden de forma independiente a las fluctuaciones de la demanda y gestionan los escenarios de error en función de los requisitos específicos del dominio.
**Patrones comunes de uso no recomendados:**
+ Se forman equipos en torno a dominios técnicos específicos, como la interfaz de usuario y la experiencia de usuario, el middleware o la base de datos, en lugar de formarse en torno a dominios empresariales específicos.
+ Las aplicaciones abarcan las responsabilidades del dominio. Los servicios que abarcan contextos delimitados pueden ser más difíciles de mantener, exigen más pruebas y requieren la participación de equipos de varios dominios en las actualizaciones del software.
+ Las dependencias de dominio, como las bibliotecas de entidades de dominio, se comparten entre los servicios, de modo que los cambios en un dominio de servicio requieren cambios en otros dominios de servicio
+ Los contratos de servicio y la lógica empresarial no expresan las entidades en un lenguaje de dominio común y coherente, lo que genera capas de traducción que complican los sistemas e incrementan los esfuerzos de depuración.
**Beneficios de establecer esta práctica recomendada:** las aplicaciones se diseñan como servicios independientes delimitados por dominios empresariales y utilizan un lenguaje empresarial común. Los servicios se pueden probar e implementar de forma independiente. Los servicios cumplen los requisitos de resiliencia específicos del dominio implementado.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
El enfoque de decisiones impulsadas por dominio (DDD) es el enfoque fundamental para diseñar y crear software en torno a los dominios empresariales. Resulta útil trabajar con un marco existente a la hora de crear servicios centrados en dominios empresariales. Si trabaja con aplicaciones monolíticas existentes, puede utilizar patrones de descomposición que ofrecen técnicas establecidas para modernizar las aplicaciones y convertirlas en servicios.
![\[Diagrama de flujo que muestra el enfoque de decisiones basadas en el dominio.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/domain-driven-decision.png)
## Pasos para la implementación
+ Los equipos pueden organizar talleres de [tormentas de eventos](https://serverlessland.com/event-driven-architecture/visuals/event-storming) para identificar rápidamente eventos, comandos, agregados y dominios en un formato de notas adhesivas más ligero.
+ Cuando las entidades y funciones del dominio se formen en un contexto de dominio, puede dividir el dominio en servicios mediante un [contexto delimitado](https://martinfowler.com/bliki/BoundedContext.html), en el que se agrupan las entidades que comparten características y atributos similares. Si el modelo está dividido en contextos, tendrá una plantilla para limitar los microservicios.
+ Por ejemplo, las entidades del sitio web de Amazon.com podrían incluir el empaquetado, la entrega, la programación, el precio, el descuento y la divisa.
+ El empaquetado, la entrega y la programación se agrupan en el contexto del envío, mientras que el precio, el descuento y la divisa se agrupan en el contexto de los precios.
+ La [descomposición de los monolitos en microservicios](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) describe los patrones para refactorizar los microservicios. El uso de patrones de descomposición por capacidad empresarial, subdominio o transacción se ajusta bien a los enfoques basados en dominios.
+ Técnicas tácticas como el [contexto burbuja](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf), que permiten introducir DDD en aplicaciones existentes o heredadas sin necesidad de reescrituras iniciales ni confirmaciones completas de las DDD. En un enfoque con contexto burbuja, se establece un pequeño contexto delimitado mediante una capa de asignación y coordinación de servicios ([capa anticorrupción](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)), que protege el modelo de dominio recién definido de influencias externas.
Después de que los equipos analicen el dominio y definan las entidades y los contratos de servicio, podrán utilizar los servicios de AWS para implementar su diseño basado en dominio como servicios basados en la nube.
+ Para comenzar el desarrollo, defina pruebas en las que se utilicen las reglas empresariales de su dominio. El desarrollo basado en pruebas (TDD) y el desarrollo basado en comportamiento (BDD) ayudan a los equipos a mantener los servicios centrados en resolver problemas empresariales.
+ Seleccione los [servicios de AWS](https://aws.amazon.com/microservices/) que mejor se adapten a los requisitos del dominio empresarial y a la [arquitectura de microservicios](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html):
+ [AWS sin servidor](https://aws.amazon.com/serverless/) permite a su equipo centrarse en una lógica de dominio específica en lugar de administrar servidores e infraestructuras.
+ Los [contenedores en AWS](https://aws.amazon.com/containers/) simplifican la administración de su infraestructura para que pueda centrarse en los requisitos de su dominio.
+ Las [bases de datos personalizadas](https://aws.amazon.com/products/databases/) le ayudan a adaptar los requisitos de su dominio al tipo de base de datos más adecuado.
+ La [creación de arquitecturas hexagonales en AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) describe un marco para integrar la lógica empresarial en los servicios que funcionan de manera inversa desde un dominio empresarial para cumplir los requisitos funcionales y, a continuación, asociar los adaptadores de integración. Los patrones que separan los detalles de la interfaz de la lógica empresarial con los servicios de AWS ayudan a los equipos a centrarse en la funcionalidad del dominio y a mejorar la calidad del software.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL03-BP01 Elección de cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Disposición de contratos de servicio por cada API](rel_service_architecture_api_contracts.md)
**Documentos relacionados:**
+ [Microservicios de AWS](https://aws.amazon.com/microservices/)
+ [Implementing Microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [How to break a Monolith into Microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [ Domain-Driven Design: Tackling Complexity in the Heart of Software ](https://www.amazon.com/gp/product/0321125215)
+ [ Building hexagonal architectures on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Decomposing monoliths into microservices ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Messages Between Bounded Contexts ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microservices ](https://www.martinfowler.com/articles/microservices.html)
+ [ Desarrollo guiado por pruebas ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Desarrollo guiado por comportamiento ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Ejemplos relacionados:**
+ [ Designing Cloud Native Microservices on AWS (from DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Herramientas relacionadas:**
+ [Bases de datos en la nube de Nube de AWS](https://aws.amazon.com/products/databases/)
+ [ Sin servidor en AWS](https://aws.amazon.com/serverless/)
+ [ Contenedores en AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Disposición de contratos de servicio por cada API
Los contratos de servicio son acuerdos documentados entre los productores y los consumidores de las API que se encuentran en una definición de API legible por máquina. 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 listas. La implementación del productor puede efectuarse en cualquier momento, siempre y cuando se cumpla el contrato. Los equipos del servicio pueden usar la pila tecnológica que prefieran para cumplir el contrato de la API.
**Resultado deseado:** las aplicaciones creadas con arquitecturas orientadas a servicios o de microservicios pueden funcionar de forma independiente y, al mismo tiempo, tener integrada una dependencia de la versión en tiempo de ejecución. Los cambios implementados en un consumidor o productor de API no interrumpen la estabilidad del sistema general cuando ambas partes utilizan el mismo contrato de API. Los componentes que se comunican a través de las API de servicio pueden llevar a cabo lanzamientos funcionales independientes, actualizar las dependencias en tiempo de ejecución o efectuar conmutaciones por error a un sitio de recuperación de desastres (DR) con poco o ningún impacto entre sí. Además, los servicios discretos pueden escalarse de forma independiente y absorber la demanda de recursos sin que sea necesario que otros servicios se escalen al unísono.
**Patrones comunes de uso no recomendados:**
+ Crear API de servicio sin esquemas estrictamente asignados. Como consecuencia, las API no se pueden usar para generar enlaces de API y las cargas útiles no se pueden validar mediante programación.
+ No adoptar una estrategia de control de versiones, lo que obliga a los usuarios de la API a actualizarla y lanzarla; de lo contrario, fallará cuando los contratos de servicio evolucionen.
+ Mensajes de error que filtran detalles de la implementación del servicio subyacente en lugar de describir los errores de integración en el contexto y el lenguaje del dominio.
+ No utilizar contratos de API para desarrollar casos de prueba ni simulaciones de implementaciones de API para probar de forma independiente los componentes del servicio.
**Beneficios de establecer esta práctica recomendada:** los sistemas distribuidos que constan de componentes que se comunican a través de contratos de servicio de API pueden mejorar la fiabilidad. Los desarrolladores pueden detectar posibles problemas al principio del proceso de desarrollo mediante la comprobación de tipos durante la compilación para comprobar que las solicitudes y las respuestas cumplan el contrato de la API y que los campos obligatorios estén presentes. Los contratos de la API proporcionan una interfaz clara y autodocumentada para las API y mejoran la interoperabilidad entre diferentes sistemas y lenguajes de programación.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Una vez que hayan identificado los dominios empresariales y determinado la segmentación de la carga de trabajo, podrá desarrollar las API de sus servicios. Primero, defina contratos de servicio legibles por máquina para las API y, a continuación, implemente una estrategia de control de versiones de API. Cuando lo tenga todo preparado para integrar servicios a través de protocolos comunes, como REST, GraphQL o eventos asíncronos, podrá incorporar servicios de AWS a su arquitectura para integrar sus componentes con contratos de API estrictamente asignados.
**Servicios de AWS para contratos de API de servicios**
Incorpore servicios de AWS como [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/) y [Amazon EventBridge](https://aws.amazon.com/eventbridge/) a su arquitectura para utilizar los contratos de servicios de API en su aplicación. Amazon API Gateway le ayuda a integrarse directamente con servicios de AWS nativos y otros servicios web. API Gateway admite el control de versiones y la [especificación de OpenAPI](https://github.com/OAI/OpenAPI-Specification). AWS AppSync es un punto de conexión de [GraphQL](https://graphql.org/) administrado que se configura mediante la definición de un esquema de GraphQL para definir una interfaz de servicio para consultas, mutaciones y suscripciones. Amazon EventBridge utiliza esquemas de eventos para definir eventos y generar enlaces de código para sus eventos.
## Pasos para la implementación
+ Primero, defina un contrato para su API. En un contrato, se expresan las capacidades de una API y se definen objetos y campos de datos estrictamente asignados para la entrada y la salida de la API.
+ Cuando configure las API en API Gateway, puede importar y exportar las especificaciones de OpenAPI para sus puntos de conexión.
+ La [importación de una definición de OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) simplifica la creación de su API y se puede integrar con la infraestructura de AWS, como herramientas de código (por ejemplo, [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) y [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/)).
+ La [exportación de una definición de API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) simplifica la integración con las herramientas de prueba de API y proporciona a los consumidores de servicios una especificación de la integración.
+ Puede definir y administrar las API de GraphQL con AWS AppSync mediante la [definición de un archivo de esquema de GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) para generar su interfaz de contrato y simplificar la interacción con modelos de REST complejos, múltiples tablas de bases de datos o servicios heredados.
+ Los proyectos de [AWS Amplify](https://aws.amazon.com/amplify/) que están integrados con AWS AppSync generan archivos de consulta de JavaScript estrictamente asignados para usarlos en su aplicación, así como una biblioteca de clientes de AWS AppSync GraphQL para tablas de [Amazon DynamoDB](https://aws.amazon.com/dynamodb/).
+ Cuando se consumen eventos de servicio de Amazon EventBridge, los eventos se ajustan a esquemas que ya existen en el registro de esquemas o que se definen con la especificación de OpenAPI. Si tiene un esquema definido en el registro, también puede generar enlaces de clientes desde el contrato de esquema para integrar el código con los eventos.
+ Amplíe la API o lleve a cabo un control de versiones. Ampliar una API es la opción más sencilla cuando se agregan campos que se pueden configurar con campos opcionales o valores predeterminados para los campos obligatorios.
+ Los contratos basados en JSON para protocolos como REST y GraphQL pueden ser una buena opción para la ampliación del contrato.
+ Los contratos basados en XML para protocolos como SOAP deben probarse con los consumidores de servicios para determinar la viabilidad de la ampliación del contrato.
+ Al llevar a cabo el control de versiones de una API, considere la posibilidad de implementar un control de versiones por proxy en el que se utilice una fachada para admitir las versiones, de modo que la lógica se pueda mantener en una única base de código.
+ Con API Gateway, puede usar [asignaciones de solicitud y respuesta](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) para simplificar la absorción de los cambios en los contratos mediante el establecimiento de una fachada que proporcione valores predeterminados para los campos nuevos o para quitar los campos eliminados de una solicitud o respuesta. Con este enfoque, el servicio subyacente puede mantener una única base de código.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL03-BP01 Elección de cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Desarrollo de servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Implementación de dependencias con acoplamiento débil](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Definición de los tiempos de espera del cliente](rel_mitigate_interaction_failure_client_timeouts.md)
**Documentos relacionados:**
+ [ ¿Qué es una interfaz de programación de aplicaciones (API)? ](https://aws.amazon.com/what-is/api/)
+ [ Implementing Microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Microservice Trade-Offs ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microservices - a definition of this new architectural term ](https://www.martinfowler.com/articles/microservices.html)
+ [ Microservicios en AWS](https://aws.amazon.com/microservices/)
+ [ Working with API Gateway extensions to OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [ OpenAPI-Specification ](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: Schemas and Types ](https://graphql.org/learn/schema/)
+ [ Amazon EventBridge code bindings ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Ejemplos relacionados:**
+ [ Amazon API Gateway: Configuring a REST API Using OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [ Amazon API Gateway to Amazon DynamoDB CRUD application using OpenAPI ](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [ Modern application integration patterns in a serverless age: API Gateway Service Integration ](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [ Implementing header-based API Gateway versioning with Amazon CloudFront ](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: Building a client application ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Videos relacionados:**
+ [ Using OpenAPI in AWS SAM to manage API Gateway ](https://www.youtube.com/watch?v=fet3bh0QA80)
**Herramientas relacionadas:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)
# Diseño de las interacciones en un sistema distribuido para evitar los errores
Los sistemas distribuidos se basan en las redes de comunicaciones para interconectar componentes, como servidores o servicios. Su carga de trabajo debe funcionar de manera fiable a pesar de la pérdida de datos o la latencia en estas redes. Los componentes del sistema distribuido deben funcionar de manera que no afecten negativamente a otros componentes o a la carga de trabajo. Estas prácticas recomendadas previenen los fallos y mejoran el tiempo medio entre errores (MTBD).
**Topics**
+ [REL04-BP01 Identificación del tipo de sistemas distribuidos de los que depende](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementación de dependencias con acoplamiento débil](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Trabajo constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Cómo hacer idempotentes las operaciones de mutación](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificación del tipo de sistemas distribuidos de los que depende
Los sistemas distribuidos pueden ser síncronos, asíncronos o por lotes. Los sistemas síncronos deben procesar las solicitudes lo más rápido posible y comunicarse entre sí mediante llamadas síncronas de solicitud y respuesta mediante protocolos HTTP/S, REST o de llamada a procedimiento remoto (RPC). Los sistemas asíncronos se comunican entre sí mediante el intercambio de datos de forma asíncrona a través de un servicio intermediario sin acoplar sistemas individuales. Los sistemas por lotes reciben un gran volumen de datos de entrada, ejecutan procesos de datos automatizados sin intervención humana y generan datos de salida.
**Resultado deseado**: diseñe una carga de trabajo que interactúe eficazmente con las dependencias síncronas, asíncronas y por lotes.
**Patrones comunes de uso no recomendados**:
+ La carga de trabajo espera indefinidamente una respuesta de sus dependencias, lo que podría provocar que se agote el tiempo de espera de los clientes de la carga de trabajo sin saber si su solicitud se ha recibido.
+ La carga de trabajo utiliza una cadena de sistemas dependientes que se llaman entre sí de forma síncrona. Para ello, cada sistema debe estar disponible y procesar correctamente una solicitud para que toda la cadena pueda tener éxito, lo que se traduce en un comportamiento y una disponibilidad general potencialmente frágiles.
+ La carga de trabajo se comunica con sus dependencias de forma asíncrona y se basa en la entrega garantizada de mensajes exactamente una vez, aunque aún es posible que se reciban mensajes duplicados.
+ La carga de trabajo no utiliza herramientas adecuadas de programación por lotes y permite la ejecución simultánea del mismo trabajo por lotes.
**Beneficios de establecer esta práctica recomendada**: es habitual que una carga de trabajo determinada implemente uno o más estilos de comunicación entre los sistemas síncronos, asíncronos o por lotes. Esta práctica recomendada le ayuda a identificar las diferentes ventajas y desventajas asociadas a cada estilo de comunicación para que su carga de trabajo pueda tolerar las interrupciones en cualquiera de sus dependencias.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada**: alto
## Guía para la implementación
Las siguientes secciones contienen una guía de implementación general y específica para cada tipo de dependencia.
**General guidance**
+ Asegúrese de que los objetivos de nivel de servicio (SLO) de rendimiento y fiabilidad que ofrecen sus dependencias cumplan los requisitos de rendimiento y fiabilidad de su carga de trabajo.
+ Utilice [los servicios de observabilidad de AWS](https://aws.amazon.com/cloudops/monitoring-and-observability) para [supervisar los tiempos de respuesta y las tasas de error](https://www.youtube.com/watch?v=or7uFFyHIX0) y asegurarse de que su dependencia presta el servicio a los niveles que necesita su carga de trabajo.
+ Identifique los posibles desafíos a los que puede enfrentarse su carga de trabajo al comunicarse con sus dependencias. Los sistemas distribuidos [se enfrentan a una amplia gama de desafíos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) que pueden aumentar la complejidad de la arquitectura, la carga operativa y el costo. Entre los desafíos comunes, se incluyen la latencia, las interrupciones de la red, la pérdida de datos, el escalado y el retardo en la replicación de datos.
+ Implemente un sistema sólido de gestión y [registro](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) de errores para ayudarle a solucionar problemas cuando su dependencia experimente problemas.
**Dependencia síncrona**
En las comunicaciones síncronas, la carga de trabajo envía una solicitud a su dependencia y bloquea la operación en espera de una respuesta. Cuando la dependencia recibe la solicitud, intenta gestionarla lo antes posible y envía una respuesta a su carga de trabajo. Un problema importante de la comunicación síncrona es que provoca un acoplamiento temporal, por lo que la carga de trabajo y sus dependencias deben estar disponibles al mismo tiempo. Cuando la carga de trabajo necesite comunicarse de forma síncrona con sus dependencias, tenga en cuenta lo siguiente:
+ La carga de trabajo no debe depender de varias dependencias síncronas para llevar a cabo una sola función. Esta cadena de dependencias aumenta la fragilidad general, porque todas las dependencias de la ruta deben estar disponibles para que la solicitud se complete correctamente.
+ Cuando una dependencia no esté en buen estado o no esté disponible, determine sus estrategias de gestión de errores y reintentos. Evite utilizar un comportamiento bimodal. El comportamiento bimodal se produce cuando la carga de trabajo presenta un comportamiento diferente en los modos normal y de error. Para obtener más información sobre el comportamiento bimodal, consulte [REL11-BP05 Uso de la estabilidad estática para evitar el comportamiento bimodal.](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ Tenga en cuenta que responder rápido a los errores es mejor que hacer esperar a la carga de trabajo. Por ejemplo, la [Guía para desarrolladores de AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html) describe cómo gestionar los reintentos y los errores al invocar funciones de Lambda.
+ Establezca tiempos de espera cuando la carga de trabajo llame a su dependencia. Esta técnica evita esperar demasiado o indefinidamente una respuesta. Para un análisis útil sobre este tema, consulte [Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/).
+ Minimice la cantidad de llamadas que se hacen desde la carga de trabajo a su dependencia para atender una sola solicitud. Si hay una conversación demasiado intensa entre ellos, aumenta el acoplamiento y la latencia.
**Dependencia asíncrona**
Para desvincular temporalmente la carga de trabajo de su dependencia, deben comunicarse de forma asíncrona. Con un enfoque asíncrono, la carga de trabajo puede continuar con cualquier otro procesamiento sin tener que esperar a que su dependencia o cadena de dependencias envíe una respuesta.
Cuando la carga de trabajo necesite comunicarse de forma asíncrona con su dependencia, tenga en cuenta lo siguiente:
+ Determine si va a utilizar la mensajería o la transmisión de eventos en función de su caso de uso y sus requisitos. La [mensajería](https://aws.amazon.com/messaging/) permite que la carga de trabajo se comunique con su dependencia mediante el envío y la recepción de mensajes a través de un agente de mensajes. La [transmisión de eventos](https://aws.amazon.com/streaming-data/) permite que su carga de trabajo y su dependencia utilicen un servicio de transmisión para publicar y suscribirse a eventos. Estas transmisiones se distribuyen como flujos continuos de datos, que deben procesarse lo antes posible.
+ La mensajería y la transmisión de eventos gestionan los mensajes de manera diferente, por lo que debe decidir si compensan en función de lo siguiente:
+ **Prioridad de mensajes:** los agentes de mensajes pueden procesar los mensajes de alta prioridad antes que los de prioridad normal. En la transmisión de eventos, todos los mensajes tienen la misma prioridad.
+ **Consumo de mensajes**: los agentes de mensajes se aseguran de que los consumidores reciban el mensaje. Los consumidores de la transmisión de eventos deben llevar un registro del último mensaje que leyeron.
+ **Orden de los mensajes**: con la mensajería, no se garantiza la recepción de los mensajes en el orden exacto en que se envíen, a menos que se utilice el enfoque de “el primero en entrar es el primero en salir” (FIFO). La transmisión de eventos siempre mantiene el orden en que se produjeron los datos.
+ **Eliminación de mensajes**: en el caso de la mensajería, el consumidor debe eliminar el mensaje después de procesarlo. El servicio de transmisión de eventos agrega el mensaje a una transmisión y permanece allí hasta que venza el periodo de retención. Esta política de eliminación hace que la transmisión de eventos sea adecuada para volver a reproducir mensajes.
+ Defina la forma en que la carga de trabajo sabe cuándo su dependencia ha terminado el trabajo. Por ejemplo, cuando la carga de trabajo invoca una [función de Lambda de forma asíncrona](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html), Lambda pone la solicitud en una cola y devuelve una respuesta de operación correcta sin información adicional. Cuando finalice el procesamiento, la función de Lambda puede [enviar el resultado a un destino](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-destinations), que se puede configurar con base en el éxito o el error.
+ Aumente la carga de trabajo para gestionar los mensajes duplicados mediante la idempotencia. La idempotencia significa que los resultados de la carga de trabajo no cambian aunque esta se genere más de una vez para el mismo mensaje. Es importante señalar que los servicios de [mensajería](https://aws.amazon.com/sqs/faqs/#FIFO_queues) o [transmisión](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html) volverán a entregar un mensaje si se produce un error en la red o si no se ha recibido un acuse de recibo.
+ Si la carga de trabajo no recibe una respuesta de su dependencia, debe volver a enviar la solicitud. Considere la posibilidad de limitar el número de reintentos para conservar los recursos de CPU, memoria y red de la carga de trabajo para gestionar otras solicitudes. La [documentación de AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html#invocation-async-errors) muestra cómo gestionar los errores en la invocación asíncrona.
+ Utilice las herramientas de observabilidad, depuración y rastreo adecuadas para administrar y utilizar la comunicación asíncrona de la carga de trabajo con su dependencia. Puede utilizar [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) para supervisar los servicios de [mensajería](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) y [transmisión de eventos](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html). También puede instrumentar su carga de trabajo con [AWS X-Ray](https://aws.amazon.com/xray/) para [obtener información](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html) rápidamente que le permita solucionar problemas.
**Dependencia por lotes**
Los sistemas por lotes toman los datos de entrada, inician una serie de trabajos para procesarlos y producen algunos datos de salida, sin intervención manual. Según el tamaño de los datos, los trabajos pueden durar desde unos minutos hasta, en algunos casos, varios días. Cuando la carga de trabajo se comunique con su dependencia por lotes, tenga en cuenta lo siguiente:
+ Defina el intervalo de tiempo en el que la carga de trabajo debe ejecutar el trabajo por lotes. La carga de trabajo puede configurar un patrón de recurrencia para invocar un sistema por lotes como, por ejemplo, cada hora o al final de cada mes.
+ Determine la ubicación de la entrada de datos y la salida de los datos procesados. Elija un servicio de almacenamiento, como [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/), [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html) y [Amazon FSx para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html), que permita que su carga de trabajo lea y escriba archivos a escala.
+ Si su carga de trabajo necesita invocar varios trabajos por lotes, puede utilizar [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc) para simplificar la orquestación de los trabajos por lotes que se ejecutan en AWS o en las instalaciones. Este [proyecto de ejemplo](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app) demuestra la orquestación de trabajos por lotes mediante Step Functions, [AWS Batch](https://aws.amazon.com/batch/) y Lambda.
+ Supervise los trabajos por lotes para detectar anomalías, como que un trabajo tarde más de lo debido en completarse. Puede utilizar herramientas como [Información de contenedores de CloudWatch](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html) para supervisar entornos y trabajos de AWS Batch. En este caso, su carga de trabajo impediría el inicio del siguiente trabajo e informaría al personal correspondiente de la excepción.
## Recursos
**Documentos relacionados**:
+ [Operaciones de Nube de AWS: supervisión y observabilidad](https://aws.amazon.com/cloudops/monitoring-and-observability)
+ [Amazon Builders' Library: los desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [REL11-BP05 Uso de la estabilidad estática para evitar el comportamiento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
+ [Guía para desarrolladores de AWS Lambda: control de errores y reintentos automáticos en AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html)
+ [Tuning AWS Java SDK HTTP request settings for latency-aware Amazon DynamoDB applications](https://aws.amazon.com/blogs/database/tuning-aws-java-sdk-http-request-settings-for-latency-aware-amazon-dynamodb-applications/)
+ [Mensajería de AWS](https://aws.amazon.com/messaging/)
+ [¿Qué son los datos de streaming?](https://aws.amazon.com/streaming-data/)
+ [Guía para desarrolladores de AWS Lambda: invocación asíncrona](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html)
+ [Preguntas frecuentes sobre Amazon Simple Queue Service: colas FIFO](https://aws.amazon.com/sqs/faqs/#FIFO_queues)
+ [Amazon Kinesis Data Streams Developer Guide: Handling Duplicate Records](https://docs.aws.amazon.com/streams/latest/dev/kinesis-record-processor-duplicates.html)
+ [Amazon Simple Queue Service Developer Guide: Available CloudWatch metrics for Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html)
+ [Amazon Kinesis Data Streams Developer Guide: Monitoring the Amazon Kinesis Data Streams Service with Amazon CloudWatch](https://docs.aws.amazon.com/streams/latest/dev/monitoring-with-cloudwatch.html)
+ [AWS X-Ray Developer Guide: AWS X-Ray concepts](https://docs.aws.amazon.com/xray/latest/devguide/xray-concepts.html)
+ [Ejemplos de AWS en GitHub: aplicación de AWS Step Functions Complex Orchestrator](https://github.com/aws-samples/aws-stepfunction-complex-orchestrator-app)
+ [AWS Batch User Guide: AWS Batch CloudWatch Container Insights](https://docs.aws.amazon.com/batch/latest/userguide/cloudwatch-container-insights.html)
**Videos relacionados**:
+ [AWS Summit SF 2022 - Full-stack observability and application monitoring with AWS (COP310)](https://www.youtube.com/watch?v=or7uFFyHIX0)
**Herramientas relacionadas**:
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Registros de Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [AWS X-Ray](https://aws.amazon.com/xray/)
+ [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html)
+ [Amazon FSx para Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc)
+ [AWS Batch](https://aws.amazon.com/batch/)
# REL04-BP02 Implementación de dependencias con acoplamiento débil
Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento débil. El acoplamiento débil ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
El desacoplamiento de las dependencias, como los sistemas de colas, los sistemas de transmisión y los flujos de trabajo, ayuda a minimizar el impacto de los cambios o los errores en un sistema. Esta separación aísla el comportamiento de un componente para que no afecte a otros que dependan de él, lo que mejora la resiliencia y la agilidad.
En sistemas de acoplamiento ajustado, los cambios en un componente pueden requerir cambios en otros componentes que dependan de él, lo que reduce el rendimiento de todos los componentes. El acoplamiento *débil* elimina esta dependencia, de forma que los componentes dependientes solo necesitan conocer la interfaz publicada y con control de versiones. La implementación de un acoplamiento débil entre las dependencias aísla un error en una de ellas para que no afecte a otra.
El acoplamiento débil permite modificar el código o agregar características a un componente y, al mismo tiempo, minimizar el riesgo para otros componentes que dependan de él. También permite una resiliencia granular de los componentes, lo que permite escalar horizontalmente o incluso cambiar la implementación subyacente de la dependencia.
Para mejorar aún más la resiliencia mediante el acoplamiento débil, haga que las interacciones entre 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. 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 de Amazon SQS o una plataforma de restringa de datos como Amazon Kinesis o AWS Step Functions.
![\[Diagrama que muestra dependencias, como los sistemas de colas y los balanceadores de carga, que tienen un acoplamiento débil\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/dependency-diagram.png)
Las colas de Amazon SQS y AWS Step Functions son solo dos formas de agregar una capa intermedia para el acoplamiento débil. Las arquitecturas basadas en eventos también se pueden crear en la Nube de AWS con Amazon EventBridge, que puede separar a los clientes (productores de eventos) de los servicios de los que dependen (consumidores de eventos). Amazon Simple Notification Service (Amazon SNS) es una solución eficaz para cuando sean necesarios mensajes de alto rendimiento, de tipo push y de varios a varios. Con el uso de temas de Amazon SNS, los sistemas de su publicador pueden repartir mensajes por una gran cantidad de puntos de conexión de suscriptores para procesarlos en paralelo.
Aunque las colas ofrecen varias ventajas, en la mayoría de sistemas en tiempo real estricto, 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.
**Resultado deseado:** la implementación de dependencias con un acoplamiento débil permite minimizar la superficie de posibles errores a nivel del componente, lo que ayuda a diagnosticar y resolver problemas. También simplifica los ciclos de desarrollo, lo que permite a los equipos implementar cambios a nivel modular sin que eso afecte al rendimiento de otros componentes que dependan de él. Este enfoque ofrece la capacidad de escalar horizontalmente a nivel de componente en función de los recursos que sean necesarios, así como de utilizar un componente que contribuye a ahorrar costos.
**Patrones comunes de uso no recomendados:**
+ Implementar una carga de trabajo monolítica.
+ Invocar directamente las API entre capas de la carga de trabajo sin la capacidad de conmutar por error ni procesar de manera asíncrona la solicitud.
+ Utilizar un acoplamiento ajustado con datos compartidos. Los sistemas de acoplamiento débil no deben compartir datos a través de bases de datos compartidas u otras formas de almacenamiento de datos de acoplamiento ajustado, que pueden reintroducir el acoplamiento ajustado y dificultar la escalabilidad.
+ Ignorar la contrapresión. La carga de trabajo debe tener la capacidad de ralentizar o detener los datos entrantes cuando un componente no pueda procesarlos al mismo ritmo.
**Beneficios de establecer esta práctica recomendada:** el acoplamiento débil ayuda a aislar el comportamiento de un componente de otros 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
Implemente dependencias con acoplamiento débil. Existen varias soluciones que permiten crear aplicaciones con un acoplamiento débil. Entre ellas, se incluyen servicios para implementar colas totalmente administradas, flujos de trabajo automatizados, reacción a eventos y API, entre otras, que pueden ayudar a aislar el comportamiento de los componentes de otros componentes y, por lo tanto, aumentar la resiliencia y la agilidad.
+ **Creación de arquitecturas basadas en eventos:** [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) le ayuda a crear arquitecturas impulsadas por eventos distribuidas y acopladas de forma débil.
+ **Implementación de colas en sistemas distribuidos:** puede utilizar [Amazon Simple Queue Service (Amazon SQS)](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html) para integrar y desacoplar sistemas distribuidos.
+ **Colocación en contenedores de los componentes como microservicios:** los [microservicios](https://aws.amazon.com/microservices/) permiten a los equipos crear aplicaciones compuestas por pequeños componentes independientes que se comunican a través de API bien definidas. [Amazon Elastic Container Service (Amazon ECS)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html) y [Amazon Elastic Kubernetes Service (Amazon EKS)](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) le pueden ayudar a comenzar con el uso de contenedores.
+ **Administración de los flujos de trabajo con Step Functions:** [Step Functions](https://aws.amazon.com/step-functions/getting-started/) le ayuda a coordinar varios servicios de AWS en flujos de trabajo flexibles.
+ **Uso de las arquitecturas de mensajería de publicación y suscripción (pub/sub):** [Amazon Simple Notification Service (Amazon SNS)](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) proporciona la entrega de mensajes de los publicadores a los suscriptores (también conocidos como productores y consumidores).
### Pasos para la implementación
+ Los componentes de una arquitectura basada en eventos se inician mediante eventos. Los eventos son acciones que ocurren en un sistema, como cuando un usuario agrega un artículo a una cesta. Cuando una acción se lleva a cabo correctamente, se genera un evento que activa el siguiente componente del sistema.
+ [ Building Event-driven Applications with Amazon EventBridge ](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [AWS re:Invent 2022 - Designing Event-Driven Integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ Los sistemas de mensajería distribuida tienen tres partes principales que deben implementarse para una arquitectura basada en colas. Incluyen los componentes del sistema distribuido, la cola que se usa para el desacoplamiento (distribuida en servidores de Amazon SQS servers) y los mensajes de la cola. Un sistema típico tiene productores que inician el mensaje en la cola y el consumidor que recibe el mensaje de la cola. La cola almacena los mensajes en varios servidores de Amazon SQS para garantizar la redundancia.
+ [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Send Messages Between Distributed Applications with Amazon Simple Queue Service ](https://aws.amazon.com/getting-started/hands-on/send-messages-distributed-applications/)
+ Los microservicios, cuando se utilizan bien, facilitan el mantenimiento y aumentan la escalabilidad, ya que los componentes de acoplamiento débil los administran equipos independientes. También permiten aislar los comportamientos en un solo componente en caso de que se hagan cambios.
+ [ Implementing Microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Let's Architect\$1 Architecting microservices with containers ](https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/)
+ Con AWS Step Functions, puede crear aplicaciones distribuidas, automatizar procesos y orquestar microservicios, entre otras cosas. La orquestación de varios componentes en un flujo de trabajo automatizado le permite desacoplar las dependencias de su aplicación.
+ [Cree un flujo de trabajo sin servidor con y AWS Step FunctionsAWS Lambda](https://aws.amazon.com/tutorials/create-a-serverless-workflow-step-functions-lambda/)
+ [ Introducción a AWS Step Functions](https://aws.amazon.com/step-functions/getting-started/)
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: Ensuring Idempotency](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](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)
+ [What Is Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ [ Break up with your monolith ](https://pages.awscloud.com/break-up-your-monolith.html)
+ [ Orchestrate Queue-based Microservices with AWS Step Functions and Amazon SQS ](https://aws.amazon.com/tutorials/orchestrate-microservices-with-message-queues-on-step-functions/)
+ [ Basic Amazon SQS architecture ](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html)
+ [ Queue-Based Architecture ](https://docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/queue-based-architecture.html)
**Videos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and 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 loose coupling, constant work, static stability)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Scalable serverless event-driven applications using Amazon SQS and Lambda ](https://www.youtube.com/watch?v=2rikdPIFc_Q)
+ [AWS re:Invent 2022 - Designing event-driven integrations using Amazon EventBridge ](https://www.youtube.com/watch?v=W3Rh70jG-LM)
+ [AWS re:Invent 2017: Elastic Load Balancing Deep Dive and Best Practices ](https://www.youtube.com/watch?v=9TwkMMogojY)
# REL04-BP03 Trabajo constante
Los sistemas pueden producir error cuando hay cambios rápidos grandes en la carga. Por ejemplo, si la carga de trabajo está llevando a cabo 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 al intentar 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
+ Trabaje constantemente para que los sistemas no tengan errores cuando haya cambios grandes y rápidos en la carga.
+ Implemente dependencias con acoplamiento débil. Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento débil. El acoplamiento débil ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
+ [Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](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)](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: Ensuring Idempotency](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Videos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and 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)](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)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Cómo hacer idempotentes las operaciones de mutación
Un servicio idempotente promete que cada solicitud se procesará una y solo una vez, de tal forma que hacer varias solicitudes idénticas tiene el mismo efecto que hacer una sola solicitud. De este modo, un cliente lo tiene más fácil para implementar los reintentos sin la preocupación de que una solicitud se procese varias veces por error. Para ello, los clientes pueden emitir solicitudes de API con un token de idempotencia, que se utiliza 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, incluso aunque haya cambiado el estado subyacente del sistema.
En un sistema distribuido, es relativamente fácil llevar a cabo una acción una vez como máximo (el cliente solo hace una solicitud) o al menos una vez (sigue haciendo la solicitud hasta que el cliente obtiene una confirmación del éxito). Es más difícil garantizar que una acción se realice *exactamente una vez*, de modo que hacer varias solicitudes idénticas tenga el mismo efecto que llevar a cabo una sola solicitud. Con el uso de tokens de idempotencia en las API, los servicios pueden recibir una solicitud de migración una o más veces sin necesidad de crear registros duplicados ni efectos secundarios.
**Resultado deseado:** un enfoque coherente, bien documentado y ampliamente adoptado para garantizar la idempotencia de todos los componentes y servicios.
**Patrones comunes de uso no recomendados:**
+ Aplica la idempotencia de forma indiscriminada, incluso cuando no es necesaria.
+ Introduce una lógica demasiado compleja para implementar la idempotencia.
+ Usa las marcas de tiempo como claves para la idempotencia. Esto puede provocar imprecisiones debido al sesgo de reloj o a que varios clientes utilicen las mismas marcas de tiempo para aplicar los cambios.
+ Almacena cargas útiles completas para la idempotencia. Con este enfoque, se guardan las cargas útiles de datos completas de cada solicitud y se sobrescriben en cada nueva solicitud. Esto puede reducir el rendimiento y afectar a la escalabilidad.
+ Genera claves de forma incoherente en todos los servicios. Sin claves coherentes, es posible que los servicios no reconozcan las solicitudes duplicadas, lo que se traduce en resultados imprevistos.
**Beneficios de establecer esta práctica recomendada:**
+ Mayor escalabilidad: el sistema puede gestionar los reintentos y las solicitudes duplicadas sin tener que realizar una lógica adicional o una compleja gestión del estado.
+ Fiabilidad mejorada: la idempotencia ayuda a los servicios a gestionar varias solicitudes idénticas de manera coherente, lo que reduce el riesgo de efectos secundarios no deseados o registros duplicados. Esto es especialmente importante en los sistemas distribuidos, donde se producen fallos de red y reintentos con frecuencia.
+ Mejora de la coherencia de datos: dado que la misma solicitud produce la misma respuesta, la idempotencia ayuda a mantener la coherencia de datos en todos los sistemas distribuidos. Esto es esencial para mantener la integridad de las transacciones y las operaciones.
+ Gestión de errores: los tokens de idempotencia simplifican la gestión de errores. Si un cliente no recibe una respuesta debido a un problema, puede reenviar la solicitud de forma segura con el mismo token de idempotencia.
+ Transparencia operativa: la idempotencia permite una mejor supervisión y registro. Los servicios pueden registrar las solicitudes con sus tokens de idempotencia, lo que facilita el rastreo y la depuración de los problemas.
+ Contrato de API simplificado: puede simplificar el contrato entre los sistemas del cliente y del servidor y reducir la preocupación por posibles errores en el procesamiento de los datos.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
En un sistema distribuido, es relativamente fácil llevar a cabo una acción una vez como máximo (el cliente solo hace una solicitud) o al menos una vez (sigue haciendo la solicitud hasta que el cliente obtiene una confirmación del funcionamiento correcto). Sin embargo, es difícil implementar un comportamiento que se dé *una sola vez*. Para lograrlo, sus clientes deben generar y proporcionar un token de idempotencia para cada solicitud.
Mediante el uso de fichas de idempotencia, un servicio puede distinguir entre solicitudes nuevas y solicitudes repetidas. Cuando un servicio recibe una solicitud con un token de idempotencia, comprueba si el token ya se ha utilizado. Si se ha utilizado el token, el servicio recupera y devuelve la respuesta almacenada. Si el token es nuevo, el servicio procesa la solicitud, almacena la respuesta junto con el token y, a continuación, devuelve la respuesta. Este mecanismo hace que todas las respuestas sean idempotentes, lo que mejora la fiabilidad y la coherencia del sistema distribuido.
La idempotencia también es un comportamiento importante de las arquitecturas basadas en eventos. Estas arquitecturas suelen estar respaldadas por una cola de mensajes como Amazon SQS, Amazon MQ, Amazon Kinesis Streams o Amazon Managed Streaming para Apache Kafka (MSK). En algunas circunstancias, un mensaje que se ha publicado solo una vez puede entregarse accidentalmente más de una vez. Cuando un publicador genera e incluye símbolos de idempotencia en los mensajes, solicita que al procesar cualquier mensaje duplicado recibido no se repita ninguna acción para el mismo mensaje. Los consumidores deben llevar un registro de cada token recibido e ignorar los mensajes que contengan tokens duplicados.
Los servicios y los consumidores también deberían transferir el token de idempotencia recibido a cualquier servicio posterior al que este llame. Todos los servicios posteriores de la cadena de procesamiento son igualmente responsables de garantizar que la idempotencia se implemente para evitar el efecto secundario de procesar un mensaje más de una vez.
### Pasos para la implementación
1. **Identifique las operaciones idempotentes**
Determine qué operaciones requieren idempotencia. Por lo general, incluyen los métodos HTTP POST, PUT y DELETE y las operaciones de inserción, actualización o eliminación de bases de datos. Las operaciones que no cambian de estado, como las consultas de solo lectura, no suelen requerir idempotencia, a menos que tengan efectos secundarios.
1. **Use identificadores únicos**
Incluye un token único en cada solicitud de operación idempotente que envíe el remitente, ya sea directamente en la solicitud o como parte de sus metadatos (por ejemplo, un encabezado HTTP). Esto permite al receptor reconocer y gestionar las solicitudes u operaciones duplicadas. Los identificadores que se utilizan habitualmente para los tokens incluyen los [identificadores únicos universales (UUID)](https://datatracker.ietf.org/doc/html/rfc9562) y los [identificadores únicos clasificables por K (KSUID)](https://github.com/segmentio/ksuid).
1. **Rastree y gestione el estado**
Mantenga el estado de cada operación o solicitud de su carga de trabajo. Esto se puede lograr almacenando el token de idempotencia y el estado correspondiente (como pendiente, completado o fallido) en una base de datos, caché u otro almacén persistente. Esta información de estado permite a la carga de trabajo identificar y gestionar las solicitudes u operaciones duplicadas.
Mantenga la coherencia y la atomicidad mediante el uso de los mecanismos de control de simultaneidad adecuados, si es necesario, como bloqueos, transacciones o controles de simultaneidad optimistas. Esto incluye el proceso de registrar el token idempotente y ejecutar todas las operaciones de mutación asociadas con la atención de la solicitud. Esto ayuda a prevenir las condiciones de carrera y verifica que las operaciones idempotentes se ejecuten correctamente.
Elimine periódicamente los tokens de idempotencia antiguos del almacén de datos para gestionar el almacenamiento y el rendimiento. Si su sistema de almacenamiento lo admite, plantéese utilizar marcas de tiempo de caducidad para los datos (conocidas como tiempo de vida o valores TTL). La probabilidad de que se reutilicen los tokens de idempotencia disminuye con el tiempo.
Las opciones de almacenamiento de AWS más comunes que se suelen utilizar para almacenar los tokens de idempotencia y el estado relacionado incluyen:
+ **Amazon DynamoDB**: DynamoDB es un servicio de base de datos NoSQL que proporciona un rendimiento de baja latencia y alta disponibilidad, lo que lo hace ideal para el almacenamiento de datos relacionados con la idempotencia. El modelo de datos de documentos y valores clave de DynamoDB permite almacenar y recuperar de forma eficiente los símbolos de idempotencia y la información de estado asociada. DynamoDB también puede hacer que los tokens de idempotencia caduquen automáticamente si la aplicación establece un valor TTL al insertarlos.
+ **Amazon ElastiCache**: ElastiCache puede almacenar tokens de idempotencia con alto rendimiento, baja latencia y bajo coste. Tanto ElastiCache (Redis) como ElastiCache (Memcached) también pueden hacer que los tokens de idempotencia caduquen automáticamente si la aplicación establece un valor TTL al insertarlos.
+ **Amazon Relational Database Service (RDS)**: puede utilizar Amazon RDS para almacenar los tokens de idempotencia y la información de estado relacionada, especialmente si su aplicación ya utiliza una base de datos relacional para otros fines.
+ **Amazon Simple Storage Service (S3)**: Amazon S3 es un servicio de almacenamiento de objetos duradero y altamente escalable que se puede utilizar para almacenar tokens de idempotencia y metadatos relacionados. Las capacidades de control de versiones de S3 pueden resultar particularmente útiles para mantener el estado de las operaciones idempotentes. La elección del servicio de almacenamiento suele depender de factores como el volumen de datos relacionados con la idempotencia, las características de rendimiento requeridas, la necesidad de durabilidad y disponibilidad y la forma en que el mecanismo de idempotencia se integra en la arquitectura de la carga de trabajo general.
1. **Implemente operaciones idempotentes**
Diseñe sus componentes de API y de carga de trabajo para que sean idempotentes. Incorpore controles de idempotencia en los componentes de su carga de trabajo. Antes de procesar una solicitud o realizar una operación, compruebe si el identificador único ya se ha procesado. Si es así, devuelva el resultado anterior en lugar de volver a ejecutar la operación. Por ejemplo, si un cliente envía una solicitud para crear un usuario, compruebe si ya existe un usuario con el mismo identificador único. Si el usuario existe, debería devolver la información del usuario existente en lugar de crear una nueva. Del mismo modo, si un consumidor de la cola recibe un mensaje con un token de idempotencia duplicado, debe ignorar el mensaje.
Cree conjuntos de pruebas integrales que validen la idempotencia de las solicitudes. Deben cubrir una amplia gama de escenarios, como las solicitudes correctas, las fallidas y las duplicadas.
Si su carga de trabajo aprovecha las funciones de AWS Lambda, puede usar Powertools para AWS Lambda. Powertools para AWS Lambda es un kit de herramientas para desarrolladores para implementar prácticas recomendadas sin servidor y aumentar la velocidad de los desarrolladores cuando trabaja con funciones de AWS Lambda. En concreto, proporciona una utilidad para convertir las funciones de Lambda en operaciones idempotentes que se pueden volver a intentar de forma segura.
1. **Comunique la idempotencia con claridad**
Documente su API y los componentes de la carga de trabajo para comunicar claramente la naturaleza idempotente de las operaciones. Esto ayuda a los clientes a entender el comportamiento esperado y cómo interactuar con su carga de trabajo de forma fiable.
1. **Monitoree y audite**:
Implemente mecanismos de supervisión y auditoría para detectar cualquier problema relacionado con la idempotencia de las respuestas, como las variaciones inesperadas de las respuestas o el exceso de gestión de solicitudes duplicadas. Esto puede ayudarlo a detectar e investigar cualquier problema o comportamiento inesperado en su carga de trabajo.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL05-BP03 Control y limitación de las llamadas de reintento](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_limit_retries.html)
+ [REL06-BP01 Supervisión de todos los componentes de la carga de trabajo (generación)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_monitor_resources.html)
+ [REL06-BP03 Envío de notificaciones (procesamiento y alarmas en tiempo real)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_monitor_aws_resources_notification_monitor.html)
+ [REL08-BP02 Integración de las pruebas funcionales como parte de la implementación](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_tracking_change_management_functional_testing.html)
**Documentos relacionados:**
+ [Amazon Builders' Library: Making retries safe with idempotent APIs](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
+ [Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [Amazon Builders' Library: Reliability, constant work, and a good cup of coffee](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [Amazon Elastic Container Service: Ensuring idempotency](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/ECS_Idempotency.html)
+ [¿Cómo puedo hacer que mi función de Lambda sea idempotente?](https://repost.aws/knowledge-center/lambda-function-idempotent)
+ [Ensuring idempotency in Amazon EC2 API requests](https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-idempotency.html)
**Videos relacionados:**
+ [Building Distributed Applications with Event-driven Architecture. Charlas técnicas en línea de AWS](https://www.youtube.com/watch?v=gA2-eqDVSng&t=1668s)
+ [AWS re:Invent 2023 - Building next-generation applications with event-driven architecture](https://www.youtube.com/watch?v=KXR17uwLEC8)
+ [AWS re:Invent 2023 - Advanced integration patterns & trade-offs for loosely coupled systems ](https://www.youtube.com/watch?v=FGKGdUiZKto)
+ [AWS re:Invent 2023 - Advanced event-driven patterns with Amazon EventBridge ](https://www.youtube.com/watch?v=6X4lSPkn4ps)
+ [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)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019 - Moving to event-driven architectures (SVS308)](https://youtu.be/h46IquqjF3E)
**Herramientas relacionadas:**
+ [Idempotencia con AWS Lambda Powertools (Java)](https://docs.powertools.aws.dev/lambda/java/utilities/idempotency/)
+ [Idempotencia con AWS Lambda Powertools (Python)](https://docs.powertools.aws.dev/lambda/python/latest/utilities/idempotency/)
+ [Página de GitHub de AWS Lambda Powertools](https://github.com/aws-powertools/)
# Diseño de 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 manera que no afecten negativamente a otros componentes o a 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.
Estas prácticas recomendadas previenen los fallos y mejoran el tiempo medio entre errores (MTBD).
**Topics**
+ [REL05-BP01 Implementación de una degradación estable para transformar las dependencias estrictas en flexibles](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Limitación de las solicitudes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Respuesta rápida a los errores y limitación de las colas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definición de los tiempos de espera del cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Creación de sistemas sin estado cuando sea posible](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementación de recursos de emergencia](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementación de una degradación estable para transformar las dependencias estrictas en flexibles
Los componentes de la aplicación deben seguir desempeñando su función principal incluso si las dependencias dejan de estar disponibles. Es posible que proporcionen datos ligeramente obsoletos, datos alternativos o incluso ningún dato. Esto garantiza que los errores localizados solo impidan lo mínimo del funcionamiento general del sistema y, al mismo tiempo, se obtenga el valor empresarial central.
**Resultado deseado:** cuando las dependencias de un componente no están en buen estado, el propio componente puede seguir funcionando, aunque con capacidad mermada. Los modos de errores de los componentes deben considerarse parte del funcionamiento normal. Los flujos de trabajo deben diseñarse de tal manera que dichos errores no produzcan un fallo total o, al menos, lleven a estados predecibles y recuperables.
**Patrones comunes de uso no recomendados:**
+ No identificar la funcionalidad empresarial principal necesaria. No probar que los componentes funcionen, incluso durante los errores de dependencia.
+ No proporcionar datos en caso de error o cuando solo una de las múltiples dependencias no está disponible y aún se pueden devolver resultados parciales.
+ Crear un estado incoherente cuando una transacción falla parcialmente.
+ No tener una forma alternativa de acceder a un almacén de parámetros central.
+ Invalidar o vaciar un estado local como resultado de un fallo de actualización sin tener en cuenta las consecuencias.
**Beneficios de establecer esta práctica recomendada:** la degradación gradual mejora la disponibilidad del sistema en su conjunto y mantiene la funcionalidad de las funciones más importantes incluso cuando hay errores.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
La implementación de una degradación gradual ayuda a minimizar el impacto de los errores de dependencia en la función de los componentes. Lo ideal sería que un componente detectara los errores de dependencia y siguiese funcionando de una forma que afectara lo menos posible a otros componentes o clientes.
Diseñar una arquitectura que permita una degradación gradual implica considerar los posibles modos de errores durante el diseño de las dependencias. Para cada modo de error, disponga de una forma de ofrecer la mayoría o, al menos la funcionalidad más crítica del componente, a las personas que llaman o a los clientes. Estos factores pueden convertirse en requisitos adicionales que se pueden probar y verificar. Lo ideal es que un componente pueda desempeñar su función principal de manera aceptable incluso cuando falla una o varias dependencias.
Se trata tanto de una cuestión empresarial como técnica. Todos los requisitos empresariales son importantes y deben cumplirse si es posible. Sin embargo, es lógico preguntarse qué debe suceder cuando no se puedan cumplir todos. Se puede diseñar un sistema para que esté disponible y sea coherente, pero en circunstancias en las que haya que eliminar un requisito, ¿cuál es más importante? En el caso del procesamiento de pagos, puede ser la coherencia. En una aplicación en tiempo real, puede ser la disponibilidad. En el caso de un sitio web orientado al cliente, la respuesta dependería de las expectativas del cliente.
Lo que esto significa depende de los requisitos del componente y de lo que deba considerarse su función principal. Por ejemplo:
+ Un sitio web de comercio electrónico podría mostrar en su página de inicio los datos de varios sistemas diferentes, como las recomendaciones personalizadas, los productos mejor clasificados y el estado de los pedidos de los clientes. Cuando un sistema anterior falla, sigue siendo lógico mostrar todo lo demás en lugar de mostrar una página de error al cliente.
+ Un componente que lleva a cabo escrituras por lotes puede seguir procesando un lote si se produce un error en una de las operaciones individuales. Implementar un mecanismo de reintento debería ser sencillo. Para hacerlo, se puede devolver a la persona que llama información sobre qué operaciones se han hecho correctamente, cuáles han fallado y por qué han fallado, o colocar las solicitudes que han fallado en una cola de mensajes fallidos para implementar reintentos asíncronos. También se debe registrar la información sobre las operaciones que han fallado.
+ Un sistema que procese las transacciones debe verificar que se ejecuten todas o ninguna de las actualizaciones individuales. En el caso de las transacciones distribuidas, se puede usar el patrón Saga para revertir operaciones anteriores en caso de que falle una operación posterior de la misma transacción. En este caso, la función principal es mantener la coherencia.
+ Los sistemas en los que el tiempo es crítico deberían contar con la capacidad de gestionar de manera oportuna las dependencias que no respondan. En estos casos, se puede utilizar el patrón del disyuntor. Cuando se agota el tiempo de espera de las respuestas de una dependencia, el sistema puede cambiar a un estado cerrado en el que no se hacen llamadas adicionales.
+ Una aplicación puede leer parámetros de un almacén de parámetros. Puede resultar útil crear imágenes de contenedores con un conjunto predeterminado de parámetros y utilizarlos en caso de que ese almacén de parámetros no esté disponible.
Tenga en cuenta que las soluciones que se adopten en caso de fallo de un componente deben probarse y ser significativamente más sencillas que la solución principal. En general, [se debe evitar el uso de estrategias alternativas](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/).
## Pasos para la implementación
Identifique las dependencias externas e internas. Considere qué tipos de errores pueden producirse en ellas. Piense en formas de minimizar el impacto negativo en los sistemas anteriores y posteriores y en los clientes durante esos errores.
A continuación, tenemos una lista de dependencias y la descripción de cómo degradar correctamente cuando fallan:
1. **Errores parciales de dependencias:** un componente puede hacer varias solicitudes a los sistemas posteriores, ya sean varias solicitudes a un sistema o una sola solicitud destinada a varios sistemas. En función del contexto empresarial, es posible que haya diferentes formas apropiadas de gestionar este problema (para obtener más información, consulte los ejemplos anteriores en la Guía de implementación).
1. **Un sistema descendente no puede procesar las solicitudes debido a la alta carga:** si las solicitudes a un sistema descendente fallan constantemente, no tiene sentido volver a intentarlo. Esto puede suponer una carga adicional para un sistema ya sobrecargado y dificultar la recuperación. Aquí se puede utilizar el patrón de disyuntor, que supervisa las llamadas que fallaron al enviarlas a un sistema posterior. Si falla un gran número de llamadas, dejará de enviar más solicitudes al sistema posterior y solo permitirá ocasionalmente el paso de las llamadas para comprobar si el sistema posterior vuelve a estar disponible.
1. **Un almacén de parámetros no está disponible:** para transformar un almacén de parámetros, se puede utilizar el almacenamiento en caché de dependencia flexible o los valores predeterminados en buen estado que se incluyen en las imágenes de contenedores o máquinas. Tenga en cuenta que estos valores predeterminados deben mantenerse actualizados e incluirse en los conjuntos de pruebas.
1. **Un servicio de supervisión u otra dependencia no funcional no está disponible:** si un componente no puede enviar registros, métricas o rastros de forma intermitente a un servicio de monitorización central, suele ser mejor seguir ejecutando las funciones empresariales como de costumbre. No registrar ni subir métricas de forma silenciosa durante mucho tiempo no suele ser aceptable. Además, algunos casos de uso pueden requerir entradas de auditoría completas para satisfacer los requisitos de cumplimiento.
1. **Es posible que una instancia principal de una base de datos relacional no esté disponible:** Amazon Relational Database Service, como casi todas las bases de datos relacionales, solo puede tener una instancia de escritura principal. Esto crea un único punto de error para las cargas de trabajo de escritura y dificulta el escalamiento. Este problema se puede mitigar parcialmente mediante el uso de una configuración Multi-AZ para lograr alta disponibilidad o de Amazon Aurora sin servidor para mejorar el escalado. Cuando los requisitos de disponibilidad son muy altos, podría ser conveniente no utilizar en absoluto el escritor principal. Para consultas de solo lectura, se pueden utilizar réplicas de lectura, que proporcionan redundancia y capacidad de escalado horizontal, no solo vertical. Las escrituras se pueden almacenar en búfer, por ejemplo, en una cola de Amazon Simple Queue Service, de modo que las solicitudes de escritura de los clientes puedan seguir aceptándose incluso si la principal no está disponible temporalmente.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: Throttle API Requests for Better Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (summarizes Circuit Breaker from “Release It\$1” book)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Error Retries and Exponential Backoff in 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/)
+ [Amazon Builders' Library: Evitar los planes alternativos en los sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Cómo evitar demoras de colas insuperables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Amazon Builders' Library: Tiempos de espera, reintentos y retardo con fluctuación](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Videos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP02 Limitación de las solicitudes
Limite las solicitudes para mitigar el agotamiento de los recursos debido a aumentos inesperados de la demanda. Las solicitudes por debajo de los índices de limitación se procesan, pero las que superan el límite definido se rechazan y se envía un mensaje que indica que la solicitud no se ha procesado a causa de la limitación.
**Resultado deseado:** la limitación de las solicitudes mitiga los grandes picos de volumen, ya sea debido a un aumento repentino del tráfico de clientes, a ataques por desbordamiento o a tormentas de reintentos, lo que permite que las cargas de trabajo sigan procesando de manera normal el volumen de solicitudes admitido.
**Patrones comunes de uso no recomendados:**
+ Las limitaciones de puntos de conexión de la API no se implementan o se mantienen en los valores predeterminados sin tener en cuenta los volúmenes esperados.
+ Los puntos de conexión de la API no se someten a pruebas de carga ni se prueban las limitaciones.
+ Los índices de solicitudes se limitan sin tener en cuenta el tamaño o la complejidad de las solicitudes.
+ Los índices o el tamaño máximos de las solicitudes se prueban, pero por separado.
+ Los recursos no se aprovisionan con los mismos límites establecidos en las pruebas.
+ No se han configurado ni considerado planes de uso para los consumidores de API de aplicación a aplicación (A2A).
+ Los consumidores de cola que escalan horizontalmente no tienen configurado un valor máximo de simultaneidad.
+ No se ha implementado la limitación de índices por dirección IP.
**Beneficios de establecer esta práctica recomendada:** las cargas de trabajo que establecen límites pueden funcionar con normalidad y procesar correctamente la carga de solicitudes aceptada en caso de que se produzcan picos de volumen inesperados. Los picos repentinos o sostenidos de solicitudes a las API y las colas se limitan y no agotan los recursos de procesamiento de solicitudes. Hay límites de índices que limitan a solicitantes individuales para que un gran volumen de tráfico desde una sola dirección IP o un único consumidor de API no agote los recursos y afecte a otros consumidores.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Los servicios deben diseñarse para procesar una capacidad de solicitudes conocida; esta capacidad se puede establecer mediante pruebas de carga. Si los índices de llegada de solicitudes superan los límites, se emite la respuesta correspondiente que indica que la solicitud no se ha procesado a causa de las limitaciones. Esto permite al consumidor gestionar el error y volver a intentarlo más tarde.
Cuando su servicio requiera la implementación de limitaciones, considere la posibilidad de implementar el algoritmo del bucket de tokens, en el que un token se refiere a una solicitud. Los tokens se recargan a un índice de limitación por segundo y se vacían de forma asíncrona a un ritmo de un token por solicitud.
![\[Diagrama que describe el algoritmo del bucket de tokens.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/token-bucket-algorithm.png)
[Amazon API Gateway](https://aws.amazon.com/api-gateway/) implementa el algoritmo del bucket de tokens de acuerdo con los límites de la cuenta y la región, y se puede configurar por cliente con planes de uso. Además, [Amazon Simple Queue Service (Amazon SQS)](https://aws.amazon.com/sqs/) y [Amazon Kinesis](https://aws.amazon.com/kinesis/) pueden almacenar las solicitudes en búfer para reducir la tasa de solicitudes y permitir tasas de limitación más altas para las solicitudes que se pueden atender. Por último, puede implementar una limitación de velocidad con [AWS WAF](https://aws.amazon.com/waf/) para limitar los consumidores de API específicos que generan una carga inusualmente alta.
## Pasos para la implementación
Puede configurar API Gateway con límites de limitación para sus API y devolver errores `429 Too Many Requests` cuando se superen los límites. Puede utilizar AWS WAF con sus puntos de conexión de AWS AppSync y API Gateway para habilitar la limitación de índices por dirección IP. Además, si su sistema tolera el procesamiento asíncrono, puede colocar los mensajes en una cola o secuencia para acelerar las respuestas a los clientes del servicio, lo que le permite ampliar los índices de limitación más altos.
Con el procesamiento asíncrono, cuando haya configurado Amazon SQS como origen de eventos de AWS Lambda, podrá [configurar la máxima simultaneidad](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) para evitar que las altas tasas de eventos consuman la cuota de ejecución simultánea de la cuenta disponible necesaria para otros servicios de su carga de trabajo o cuenta.
Si bien API Gateway proporciona una implementación administrada del bucket de tokens, en los casos en que no pueda usar API Gateway, puede utilizar las implementaciones de código abierto específicas de cada lenguaje (consulte los ejemplos relacionados en Recursos) del bucket de tokens para sus servicios.
+ Comprenda y configure los [límites de limitación de API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) en la cuenta por región, API por etapa y clave de API por nivel de plan de uso.
+ Aplique [reglas de limitación de tasas de AWS WAF](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/) a API Gateway y a los puntos de conexión de AWS AppSync para protegerse contra las inundaciones y bloquear las IP maliciosas. Las reglas de limitación de índices también se pueden configurar en las claves de API de AWS AppSync para los consumidores de A2A.
+ Analice si necesita un control de limitación superior a la limitación de índices para las API de AWS AppSync y, de ser así, configure una API Gateway enfrente de su punto de conexión de AWS AppSync.
+ Cuando las colas de Amazon SQS se configuran como activadores para los consumidores de colas de Lambda, defina la [simultaneidad máxima](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency) en un valor que procese lo suficiente como para cumplir sus objetivos de nivel de servicio, pero que no consuma los límites de simultaneidad que afecten a otras funciones de Lambda. Considere la posibilidad de configurar la simultaneidad reservada en otras funciones de Lambda de la misma cuenta y región cuando consuma colas con Lambda.
+ Utilice API Gateway con integraciones de servicios nativos para Amazon SQS o Kinesis para almacenar en búfer las solicitudes.
+ Si no puede utilizar API Gateway, consulte las bibliotecas específicas del lenguaje para implementar el algoritmo del bucket de tokens para su carga de trabajo. Consulte la sección de ejemplos e investigue por su cuenta para encontrar una biblioteca adecuada.
+ Pruebe los límites que tiene pensado establecer o que va a permitir que se aumenten, y documente los límites probados.
+ No aumente los límites por encima de lo que establezca en las pruebas. Cuando aumente un límite, antes de aplicar ese aumento, compruebe que los recursos aprovisionados sean equivalentes o superiores a los de las situaciones de prueba.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL04-BP03 Trabajo constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
**Documentos relacionados:**
+ [Amazon API Gateway: Throttle API Requests for Better Throughput](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [AWS WAF: Rate-based rule statement ](https://docs.aws.amazon.com/waf/latest/developerguide/waf-rule-statement-type-rate-based.html)
+ [ Introducing maximum concurrency of AWS Lambda when using Amazon SQS as an event source ](https://aws.amazon.com/blogs/compute/introducing-maximum-concurrency-of-aws-lambda-functions-when-using-amazon-sqs-as-an-event-source/)
+ [AWS Lambda: Maximum Concurrency ](https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html#events-sqs-max-concurrency)
**Ejemplos relacionados:**
+ [ The three most important AWS WAF rate-based rules ](https://aws.amazon.com/blogs/security/three-most-important-aws-waf-rate-based-rules/)
+ [ Java Bucket4j ](https://github.com/bucket4j/bucket4j)
+ [ Python token-bucket ](https://pypi.org/project/token-bucket/)
+ [ Node token-bucket ](https://www.npmjs.com/package/tokenbucket)
+ [ .NET System Threading Rate Limiting ](https://www.nuget.org/packages/System.Threading.RateLimiting)
**Videos relacionados:**
+ [ Implementing GraphQL API security best practices with AWS AppSync](https://www.youtube.com/watch?v=1ASMLeJ_15U)
**Herramientas relacionadas:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon Kinesis ](https://aws.amazon.com/kinesis/)
+ [AWS WAF](https://aws.amazon.com/waf/)
+ [Sala de espera virtual en AWS](https://aws.amazon.com/solutions/implementations/virtual-waiting-room-on-aws/)
# REL05-BP03 Control y limitación de las llamadas de reintento
Utilice un retroceso exponencial para reintentar las solicitudes a intervalos progresivamente más largos entre cada reintento. Introduzca una fluctuación entre reintentos para aleatorizar los intervalos de reintentos. Limite el número máximo de reintentos.
**Resultado deseado:** entre los componentes típicos de un sistema de software distribuido se incluyen servidores, equilibradores de carga, bases de datos y servidores DNS. Durante el funcionamiento normal, estos componentes pueden responder a las solicitudes con errores temporales o limitados, y también con errores que serían persistentes independientemente de los reintentos. Cuando los clientes hacen solicitudes a los servicios, esas solicitudes consumen recursos, como memoria, subprocesos, conexiones, puertos o cualquier otro recurso limitado. Controlar y limitar los reintentos es una estrategia para liberar y minimizar el consumo de recursos, de modo que los componentes del sistema sometidos a presión no se sobrecarguen.
Cuando se agota el tiempo de espera de las solicitudes del cliente o se reciben respuestas de error, deben determinar si deben volver a intentarlo o no. Si lo vuelven a intentar, lo hacen con un retroceso exponencial con fluctuaciones y un valor de reintento máximo. Como resultado, los servicios y procesos de backend tienen menos carga y más tiempo para recuperarse automáticamente, lo que se traduce en una recuperación más rápida y una tramitación satisfactoria de las solicitudes.
**Patrones comunes de uso no recomendados:**
+ Implementar los reintentos sin agregar valores de retroceso exponencial, fluctuación y reintentos máximos. El retroceso y la fluctuación ayudan a evitar picos de tráfico artificiales debidos a reintentos coordinados involuntariamente a intervalos comunes.
+ Implementar reintentos sin probar sus efectos o asumir que los reintentos ya están integrados en un SDK sin probar los escenarios de reintento.
+ No entender los códigos de error publicados de las dependencias, lo que lleva a volver a intentar todos los errores, incluidos los que tienen una causa clara que indica una falta de permisos, un error de configuración u otro problema que es de esperar que no se pueda resolver sin una intervención manual.
+ No utilizar prácticas de observabilidad, como supervisión y alertas en caso de errores de servicio repetidos, para conocer problemas subyacentes y poder solucionarlos.
+ Desarrollar mecanismos de reintento personalizados cuando son suficientes las capacidades de reintento integradas o de terceros.
+ Reintentar en varias capas de la pila de aplicaciones de una forma que se acumulen, lo que consume aún más recursos en una tormenta de reintentos. Asegúrese de entender cómo afectan estos errores a las dependencias en las que se basa y, a continuación, implemente los reintentos en un solo nivel.
+ Reintentar llamadas de servicio que no son idempotentes, lo que provoca efectos secundarios inesperados, como resultados duplicados.
**Beneficios de establecer esta práctica recomendada:** los reintentos ayudan a los clientes a obtener los resultados deseados cuando las solicitudes fallan, pero también consumen más tiempo del servidor para obtener las respuestas satisfactorias que desean. Cuando los errores son poco frecuentes o transitorios, los reintentos funcionan bien. Cuando los errores se deben a una sobrecarga de recursos, los reintentos pueden empeorar las cosas. Agregar un retroceso exponencial con fluctuaciones para los reintentos de los clientes permite que los servidores se recuperen cuando los errores se deben a una sobrecarga de recursos. La fluctuación evita que haya picos de solicitudes y el retroceso disminuye el escalamiento de la carga provocado por la adición de reintentos a la carga normal de solicitudes. Por último, es importante configurar un número de reintentos máximo o un tiempo transcurrido máximo para evitar que se acumulen tareas pendientes que generen errores metaestables.
**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 aleatorizar los intervalos de reintento y limite el número máximo de reintentos.
Algunos AWS SDK implementan los reintentos y el retroceso exponencial de forma predeterminada. Utilice estas implementaciones de AWS integradas cuando corresponda en su carga de trabajo. Implemente una lógica similar en su carga de trabajo cuando llame a servicios que sean idempotentes y en los que los reintentos mejoren la disponibilidad de sus clientes. Decida cuáles son los tiempos de espera y cuándo dejar de reintentar según su caso de uso. Cree y ejecute situaciones de prueba para esos casos de uso de reintentos.
## Pasos para la implementación
+ Determine la capa óptima de la pila de aplicaciones para implementar los reintentos de los servicios de los que depende su aplicación.
+ Tenga en cuenta que los SDK existentes implementan estrategias de reintento probadas con retroceso exponencial y fluctuaciones para el lenguaje que elija, y dé preferencia a estas estrategias en lugar de escribir sus propias implementaciones de reintentos.
+ Verifique que los [servicios sean idempotentes](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) antes de implementar los reintentos. Una vez implementados, asegúrese de que se prueben y se utilicen regularmente en producción.
+ Al llamar a las API del servicio de AWS, utilice los [AWS SDK](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) y [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html) y comprenda las opciones de configuración de reintentos. Determine si los valores predeterminados funcionan para su caso de uso, pruébelos y ajústelos según sea necesario.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL04-BP04 Cómo hacer idempotentes las operaciones de mutación](rel_prevent_interaction_failure_idempotent.md)
+ [REL05-BP02 Limitación de las solicitudes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP04 Respuesta rápida a los errores y limitación de las colas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definición de los tiempos de espera del cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL11-BP01 Supervisión de todos los componentes de la carga de trabajo para detectar errores](rel_withstand_component_failures_monitoring_health.md)
**Documentos relacionados:**
+ [Error Retries and Exponential Backoff in AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Amazon Builders' Library: Tiempos de espera, reintentos y retardo con fluctuación](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Exponential Backoff and Jitter ](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-jitter/)
+ [ Making retries safe with idempotent APIs ](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)
**Ejemplos relacionados:**
+ [ Spring Retry ](https://github.com/spring-projects/spring-retry)
+ [ Resilience4j Retry ](https://resilience4j.readme.io/docs/retry)
**Videos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Herramientas relacionadas:**
+ [AWS SDKs and Tools: Retry behavior ](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html)
+ [AWS Command Line Interface: Reintentos de AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-retries.html)
# REL05-BP04 Respuesta rápida a los errores y limitación de las colas
Cuando un servicio no pueda responder correctamente a una solicitud, responda rápido a los errores. Esto permite que se liberen los recursos asociados a una solicitud y que un servicio se recupere cuando se le agotan los recursos. La respuesta rápida a los errores es un patrón de diseño de software bien establecido que se puede utilizar para conseguir cargas de trabajo enormemente fiables en la nube. Las colas también son un patrón de integración empresarial bien establecido que puede suavizar la carga y permitir a los clientes liberar recursos cuando se pueda tolerar el procesamiento asíncrono. Cuando un servicio puede responder correctamente en condiciones normales, pero falla cuando el índice de solicitudes es demasiado alto, utilice una cola para almacenar en búfer las solicitudes. Sin embargo, no permita que se acumulen largas colas de tareas pendientes, ya que eso podría hacer que se procesaran solicitudes obsoletas a las que un cliente ya ha renunciado.
**Resultado deseado:** cuando los sistemas sufren contención de recursos, tiempos de espera, excepciones o errores grises que hacen que los objetivos de nivel de servicio sean inalcanzables, las estrategias de respuesta rápida a los errores permiten recuperar el sistema más rápido. Los sistemas que deben absorber los picos de tráfico y pueden adaptarse al procesamiento asíncrono pueden mejorar la fiabilidad al permitir a los clientes liberar rápidamente las solicitudes mediante el uso de colas para almacenar en búfer las solicitudes a los servicios de backend. Cuando las solicitudes a las colas se almacenan en búfer, se implementan estrategias de administración de colas para evitar retrasos insuperables.
**Patrones comunes de uso no recomendados:**
+ Implementar colas de mensajes, pero no configurar colas de mensajes fallidos (DLQ) ni alarmas en los volúmenes de DLQ para detectar cuándo está fallando un sistema.
+ No medir la antigüedad de los mensajes de una cola, que es una medida de la latencia para saber cuándo los usuarios de la cola sufren retrasos o producen errores que dan lugar a reintentos.
+ No borrar los mensajes pendientes de una cola cuando no sirve de nada procesar esos mensajes si la empresa ya no necesita hacerlo.
+ Configurar colas de primero en entrar/primero en salir (FIFO) cuando las colas de último en entrar, primero en salir (LIFO) responderían mejor a las necesidades de los clientes, por ejemplo, cuando no se requieren pedidos estrictos y el procesamiento pendiente retrasa todas las solicitudes nuevas y urgentes, lo que hace que se infrinjan los niveles de servicio de todos los clientes.
+ Exponer las colas internas a los clientes en lugar de exponer las API que administran la entrada de trabajo y colocan las solicitudes en colas internas.
+ Combinar demasiados tipos de solicitudes de trabajo en una sola cola puede agravar las condiciones de las tareas pendientes al distribuir la demanda de recursos entre los tipos de solicitudes.
+ Procesar solicitudes complejas y simples en la misma cola, a pesar de necesitar diferentes niveles de supervisión, tiempos de espera y asignaciones de recursos.
+ No validar las entradas ni utilizar afirmaciones para implementar mecanismos de respuesta rápida a los errores en el software que envíen las excepciones a componentes de nivel superior que puedan gestionar los errores con facilidad.
+ No eliminar los recursos que fallan del enrutamiento de solicitudes, especialmente cuando los errores grises emiten tanto éxitos como errores debido a bloqueos y reinicios, errores de dependencia intermitentes, una reducción de la capacidad o la pérdida de paquetes de red.
**Beneficios de establecer esta práctica recomendada:** los sistemas que responden rápido a los errores son más fáciles de depurar y corregir y, a menudo, revelan problemas de codificación y configuración antes de que las versiones se publiquen en producción. Los sistemas que incorporan estrategias de puesta en cola eficaces tienen una mayor resiliencia y fiabilidad a los picos de tráfico y a las condiciones de errores intermitentes del sistema.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Las estrategias de respuesta rápida a los errores pueden codificarse en soluciones de software y también configurarse en la infraestructura. Además de la respuesta rápida a los errores, las colas son una técnica arquitectónica sencilla, pero potente, para desacoplar los componentes del sistema sin problemas de carga. [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) proporciona capacidades para supervisar los errores y alertar en caso de que existan. Una vez que se sabe que un sistema está fallando, se pueden invocar estrategias de mitigación, como el alejamiento de los recursos deteriorados. Cuando los sistemas implementan colas con [Amazon SQS](https://aws.amazon.com/sqs/) y otras tecnologías de cola para facilitar la carga, deben considerar cómo administrar los atrasos en las colas, así como los errores en el consumo de mensajes.
## Pasos para la implementación
+ Implemente afirmaciones programáticas o métricas específicas en su software y utilícelas para alertar explícitamente sobre problemas del sistema. Amazon CloudWatch le ayuda a crear métricas y alarmas basadas en el patrón de registro de la aplicación y la instrumentación del SDK.
+ Utilice métricas y alarmas de CloudWatch para alejarse de los recursos deteriorados que aumentan la latencia del procesamiento o que no procesan las solicitudes de forma reiterada.
+ Utilice el procesamiento asíncrono diseñando API que acepten solicitudes y las anexen a las colas internas mediante Amazon SQS y, a continuación, respondan al cliente que produce los mensajes con un mensaje de éxito, de modo que el cliente pueda liberar recursos y continuar con otras tareas mientras los consumidores de la cola del backend procesan las solicitudes.
+ Para medir y supervisar la latencia de procesamiento de las colas, genere una métrica de CloudWatch cada vez que se retire un mensaje de una cola mediante la comparación en ese momento con la marca de tiempo del mensaje.
+ Cuando los errores impidan procesar correctamente los mensajes o los picos de tráfico en los volúmenes que no se pueden procesar dentro de los acuerdos de nivel de servicio, aparte el tráfico antiguo o excesivo y colóquelo en una cola secundaria. Esto permite procesar de forma prioritaria los trabajos nuevos y dejar los antiguos para cuando haya capacidad disponible. Esta técnica es una aproximación al procesamiento LIFO y permite que el sistema procese normalmente todos los trabajos nuevos.
+ Utilice colas de mensajes fallidos o redireccione las colas para sacar de la lista de espera los mensajes que no se puedan procesar y colocarlos en una ubicación que pueda investigarse y resolverse más adelante
+ Vuelva a intentarlo o, cuando sea tolerable, elimine los mensajes antiguos. Para ello, compárelos en ese momento con la marca de tiempo del mensaje y descarte los mensajes que ya no sean pertinentes para el cliente que los ha solicitado.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL04-BP02 Implementación de dependencias con acoplamiento débil](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP02 Limitación de las solicitudes](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL06-BP02 Definición y cálculo de métricas (agregación)](rel_monitor_aws_resources_notification_aggregation.md)
+ [REL06-BP07 Supervisión del seguimiento de las solicitudes de principio a fin en todo el sistema](rel_monitor_aws_resources_end_to_end.md)
**Documentos relacionados:**
+ [ Cómo evitar demoras de colas insuperables ](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs/)
+ [Fail Fast](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [ ¿Cómo puedo evitar que se acumulen mensajes en mi cola de Amazon SQS? ](https://repost.aws/knowledge-center/sqs-message-backlog)
+ [ Elastic Load Balancing: Zonal Shift ](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/zonal-shift.html)
+ [ Amazon Application Recovery Controller: Routing control for traffic failover ](https://docs.aws.amazon.com/r53recovery/latest/dg/getting-started-routing-controls.html)
**Ejemplos relacionados:**
+ [ Enterprise Integration Patterns: Dead Letter Channel ](https://www.enterpriseintegrationpatterns.com/patterns/messaging/DeadLetterChannel.html)
**Videos relacionados:**
+ [AWS re:Invent 2022 - Operating highly available Multi-AZ applications](https://www.youtube.com/watch?v=mwUV5skJJ0s)
**Herramientas relacionadas:**
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [ Amazon MQ ](https://aws.amazon.com/amazon-mq/)
+ [AWS IoT Core](https://aws.amazon.com/iot-core/)
+ [ Amazon CloudWatch ](https://aws.amazon.com/cloudwatch/)
# REL05-BP05 Definición de los tiempos de espera del cliente
Defina tiempos de espera adecuados para las conexiones y las solicitudes, verifíquelos sistemáticamente y no use los valores predeterminados, ya que no tienen en cuenta las características específicas de la carga de trabajo.
**Resultado deseado:** en los tiempos de espera de los clientes, se debe tener en cuenta el costo para el cliente, el servidor y la carga de trabajo asociados a la espera de las solicitudes que tardan un tiempo anormal en completarse. Dado que no es posible conocer la causa exacta de ningún tiempo de espera, los clientes deben utilizar el conocimiento de los servicios para fijar expectativas sobre las causas probables y los tiempos de espera adecuados
El tiempo de espera de las conexiones del cliente se agota en función de los valores configurados. Cuando el tiempo de espera se agota, los clientes toman la decisión de dar marcha atrás y volver a intentarlo o abrir un [disyuntor](https://martinfowler.com/bliki/CircuitBreaker.html). Estos patrones evitan que se emitan solicitudes que puedan agravar una condición de error subyacente.
**Patrones comunes de uso no recomendados:**
+ No estar al tanto de los tiempos de espera del sistema o de los tiempos de espera predeterminados.
+ No estar al tanto del tiempo normal de finalización de las solicitudes.
+ No conocer las posibles causas por las que las solicitudes tardan un tiempo anormalmente largo en completarse ni los costos para el rendimiento del cliente, el servicio o la carga de trabajo asociados a la espera a que se completen.
+ No conocer la probabilidad de que la red deteriorada haga que una solicitud falle solo una vez que se haya agotado el tiempo de espera, ni de los costos que supone para el rendimiento del cliente y la carga de trabajo no utilizar un tiempo de espera más corto.
+ No probar escenarios de tiempo de espera tanto para las conexiones como para las solicitudes.
+ Definir tiempos de espera demasiado altos, lo que puede provocar tiempos de espera prolongados y aumentar el uso de los recursos.
+ Definir tiempos de espera demasiado bajos, lo que provoca errores artificiales.
+ Pasar por alto los patrones para solucionar los errores de tiempo de espera de las llamadas remotas, como disyuntores y reintentos.
+ No considerar la posibilidad de supervisar los índices de errores de las llamadas de servicio, los objetivos de nivel de servicio referentes a la latencia y los valores atípicos de latencia. Estas métricas pueden proporcionar información sobre tiempos de espera agresivos o permisivos
**Beneficios de establecer esta práctica recomendada:** los tiempos de espera de las llamadas remotas están configurados y los sistemas están diseñados para gestionar los tiempos de espera correctamente, de modo que los recursos se conserven cuando las llamadas remotas responden con una lentitud anormal y los clientes del servicio gestionan correctamente los errores de tiempo de espera.
**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 cualquier llamada de dependencia del servicio y, normalmente, en todas las llamadas de los procesos. Muchos marcos integran capacidades de tiempo de espera, pero tenga cuidado, ya que algunos tienen valores predeterminados que son infinitos o superiores a lo aceptable para sus objetivos de servicio. 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 que las solicitudes hacen demasiados reintentos. En algunos casos, esto puede producir una interrupción completa si se reintentan todas las solicitudes.
Tenga en cuenta lo siguiente al determinar las estrategias de tiempo de espera:
+ Las solicitudes pueden tardar más de lo normal en procesarse debido a su contenido, a deficiencias en un servicio de destino o a un error en la partición de la red.
+ Las solicitudes con contenido anormalmente caro podrían consumir recursos innecesarios del servidor y del cliente. En este caso, si se agota el tiempo de espera de estas solicitudes y no se vuelven a intentar, se pueden conservar los recursos. Los servicios también deberían protegerse del contenido anormalmente caro con restricciones y tiempos de espera del lado del servidor.
+ Se puede agotar el tiempo de espera y volver a intentar las solicitudes que tarden un tiempo anormalmente largo debido a una interrupción del servicio. Se deben tener en cuenta los costos del servicio de la solicitud y el reintento, pero si la causa es una deficiencia localizada, es probable que el reintento no sea caro y reduzca el consumo de recursos del cliente. El tiempo de espera también puede liberar recursos del servidor según la naturaleza de la deficiencia.
+ Se puede agotar el tiempo de espera y volver a intentar las solicitudes que tarden mucho en completarse porque la red no ha podido entregar la solicitud o la respuesta. Como la solicitud o la respuesta no se han entregado, el resultado habría sido un error independientemente del tiempo de espera. En este caso, el tiempo de espera no liberará los recursos del servidor, pero sí liberará los recursos del cliente y mejorará el rendimiento de la carga de trabajo.
Aproveche patrones de diseño bien establecidos, como los reintentos y los disyuntores, para gestionar los tiempos de espera correctamente y ofrecer enfoques de respuesta rápida a los errores. [AWS Los SDK](https://docs.aws.amazon.com/index.html#sdks) y [AWS CLI](https://aws.amazon.com/cli/) permiten configurar los tiempos de espera de conexión y solicitud y los reintentos con retrocesos y fluctuaciones exponenciales. Las funciones de [AWS Lambda](https://aws.amazon.com/lambda/) permiten configurar los tiempos de espera y, con [AWS Step Functions](https://aws.amazon.com/step-functions/), se pueden crear disyuntores con poco código que aprovechen las integraciones predefinidas con servicios de AWS y SDK. [AWS App Mesh](https://aws.amazon.com/app-mesh/) Envoy incluye capacidades de tiempo de espera y de disyuntor.
## Pasos para la implementación
+ Configure tiempos de espera en las llamadas de servicio remotas y aproveche las características integradas de tiempo de espera del lenguaje o las bibliotecas de tiempo de espera de código abierto.
+ Cuando su carga de trabajo haga llamadas con un AWS SDK, consulte la documentación para ver la configuración del tiempo de espera específica de cada lenguaje.
+ [ Python ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html)
+ [ PHP ](https://docs.aws.amazon.com/aws-sdk-php/v3/api/class-Aws.DefaultsMode.Configuration.html)
+ [ .NET ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [ Ruby ](https://docs.aws.amazon.com/sdk-for-ruby/v3/developer-guide/timeout-duration.html)
+ [ Java ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [ Go ](https://aws.github.io/aws-sdk-go-v2/docs/configuring-sdk/retries-timeouts/#timeouts)
+ [ Node.js ](https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/Config.html)
+ [ C\$1\$1 ](https://docs.aws.amazon.com/sdk-for-cpp/v1/developer-guide/client-config.html)
+ Cuando utilice AWS SDK o comandos de la AWS CLI en su carga de trabajo, defina los valores predeterminados de tiempo de espera mediante la configuración de los [valores predeterminados de configuración](https://docs.aws.amazon.com/sdkref/latest/guide/feature-smart-config-defaults.html) de AWS para `connectTimeoutInMillis` y `tlsNegotiationTimeoutInMillis`.
+ Aplique las [opciones de línea de comandos](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html) `cli-connect-timeout` y `cli-read-timeout` para controlar comandos únicos de la AWS CLI para los servicios de AWS.
+ Supervise las llamadas de servicio remotas para comprobar si hay tiempos de espera y configure alarmas en caso de errores persistentes para poder gestionar los escenarios de error de forma proactiva.
+ Implemente [métricas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) y la [detección de anomalías de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) en los índices de error de las llamadas, los objetivos de nivel de servicio en lo que se refiere a la latencia y los valores atípicos de latencia para proporcionar información sobre la administración de tiempos de espera demasiado agresivos o permisivos.
+ Configure los tiempos de espera en las [funciones de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html#configuration-timeout-console).
+ Los clientes de API Gateway deben implementar sus propios reintentos al gestionar los tiempos de espera. API Gateway admite un [tiempo de espera de integración de 50 milisegundos a 29 segundos](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html#api-gateway-execution-service-limits-table) para las integraciones posteriores y no lo vuelve a intentar cuando la integración solicita el tiempo de espera.
+ Implemente el patrón de [disyuntor](https://martinfowler.com/bliki/CircuitBreaker.html) para que no se hagan llamadas remotas cuando se agote el tiempo de espera. Abra el circuito para evitar llamadas fallidas y ciérrelo cuando las llamadas respondan con normalidad.
+ Para las cargas de trabajo basadas en contenedores, consulte las funciones de [App Mesh Envoy](https://docs.aws.amazon.com/app-mesh/latest/userguide/envoy.html) para aprovechar los tiempos de espera y los disyuntores integrados.
+ Utilice AWS Step Functions para crear disyuntores de poco código para las llamadas de servicio remotas, especialmente cuando se utilizan AWS SDK nativos e integraciones de Step Functions compatibles para simplificar la carga de trabajo.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Respuesta rápida a los errores y limitación de las colas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL06-BP07 Supervisión del seguimiento de las solicitudes de principio a fin en todo el sistema](rel_monitor_aws_resources_end_to_end.md)
**Documentos relacionados:**
+ [AWS SDK: Retries and Timeouts](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon Builders' Library: Tiempos de espera, reintentos y retardo con fluctuación](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [ Cuotas de Amazon API Gateway y notas importantes ](https://docs.aws.amazon.com/apigateway/latest/developerguide/limits.html)
+ [AWS Command Line Interface: Command line options ](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html)
+ [AWS SDK for Java 2.x: Configure API Timeouts ](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/best-practices.html#bestpractice5)
+ [AWS Botocore using the config object and Config Reference ](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html#using-the-config-object)
+ [AWS SDK para .NET: Retries and Timeouts ](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [AWS Lambda: Configuración de funciones de Lambda ](https://docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html)
**Ejemplos relacionados:**
+ [ Using the circuit breaker pattern with AWS Step Functions and Amazon DynamoDB ](https://aws.amazon.com/blogs/compute/using-the-circuit-breaker-pattern-with-aws-step-functions-and-amazon-dynamodb/)
+ [ Martin Fowler: CircuitBreaker ](https://martinfowler.com/bliki/CircuitBreaker.html?ref=wellarchitected)
**Herramientas relacionadas:**
+ [AWS SDK ](https://docs.aws.amazon.com/index.html#sdks)
+ [AWS Lambda](https://aws.amazon.com/lambda/)
+ [ Amazon SQS ](https://aws.amazon.com/sqs/)
+ [AWS Step Functions](https://aws.amazon.com/step-functions/)
+ [AWS Command Line Interface](https://aws.amazon.com/cli/)
# REL05-BP06 Creación de sistemas sin estado cuando sea posible
Los sistemas 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.
Cuando los usuarios o los servicios interactúan con una aplicación, suelen llevar a cabo 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 de EC2 y las funciones de AWS Lambda) puede dar servicio a cualquier solicitud.
**Beneficios de establecer esta práctica recomendada:** los sistemas que se han diseñado para no tener estado se adaptan mejor al escalado horizontal, lo que permite agregar o eliminar capacidad en función de la fluctuación del tráfico y la demanda. También son intrínsecamente resistentes a los errores y proporcionan flexibilidad y agilidad en el desarrollo de aplicaciones.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Cree aplicaciones sin estado. Las aplicaciones sin estado permiten el escalado horizontal y toleran el error de un nodo individual. Analice y comprenda los componentes de la aplicación que mantienen el estado dentro de la arquitectura. Esto le ayuda a evaluar el posible impacto de la transición a un diseño sin estado. Una arquitectura sin estado desacopla los datos del usuario y descarga los datos de la sesión. Esto proporciona la flexibilidad para escalar cada componente de forma independiente para cumplir con las diferentes demandas de carga de trabajo y optimizar el uso de los recursos.
### Pasos para la implementación
+ Identifique y comprenda los componentes con estado de la aplicación.
+ Para desacoplar los datos, separe y administre los datos de usuario de la lógica principal de la aplicación.
+ [Amazon Cognito](https://aws.amazon.com/cognito/) puede desacoplar los datos de usuario del código de la aplicación mediante características, tales como [grupos de identidades](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-identity-pools.html), [grupos de usuarios](https://docs.aws.amazon.com/cognito/latest/developerguide/getting-started-with-cognito-user-pools.html) y [Amazon Cognito Sync](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-sync.html).
+ Para usar [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) a fin de desacoplar los datos de usuario, almacene los secretos en una ubicación segura y centralizada. Esto significa que el código de la aplicación no necesita almacenar secretos, lo que la hace más segura.
+ Plantéese utilizar [Amazon S3](https://aws.amazon.com/s3/) para almacenar datos no estructurados y de gran volumen, como imágenes y documentos. La aplicación puede recuperar estos datos cuando sea necesario, lo que elimina la necesidad de almacenarlos en la memoria.
+ Utilice [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) para almacenar información, como, por ejemplo, perfiles de usuario. La aplicación puede consultar estos datos prácticamente en tiempo real.
+ Descargue los datos de la sesión en una base de datos, caché o archivos externos.
+ [Amazon ElastiCache](https://aws.amazon.com/elasticache/), Amazon DynamoDB, [Amazon Elastic File System](https://aws.amazon.com/efs/) (Amazon EFS) y [Amazon MemoryDB](https://aws.amazon.com/memorydb/) son ejemplos de servicios de AWS que puede usar para descargar datos de sesión.
+ Diseñe una arquitectura sin estado después de identificar qué datos de estado y de usuario deben conservarse con la solución de almacenamiento que elija.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL11-BP03 Automatización de la reparación en todas las capas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_auto_healing_system.html)
**Documentos relacionados:**
+ [Amazon Builders' Library: Evitar los planes alternativos en los sistemas distribuidos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [Amazon Builders' Library: Cómo evitar demoras de colas insuperables](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [Amazon Builders' Library: Desafíos y estrategias del almacenamiento en caché](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [Prácticas recomendadas para el nivel web sin estado en AWS](https://docs.aws.amazon.com/whitepapers/latest/best-practices-wordpress/stateless-web-tier.html)
# REL05-BP07 Implementación de recursos de emergencia
Los recursos de emergencia son procesos rápidos que pueden mitigar el impacto en la disponibilidad de la carga de trabajo.
Los recursos de emergencia desactivan, limitan o cambian el comportamiento de componentes o dependencias mediante mecanismos conocidos y probados. Esto puede aliviar las deficiencias de la carga de trabajo causadas por el agotamiento de los recursos debido a los aumentos inesperados de la demanda y reducir el impacto de los fallos en los componentes no críticos de la carga de trabajo.
**Resultado deseado:** al implementar recursos de emergencia, puede establecer procesos que se sabe que son buenos para mantener la disponibilidad de los componentes críticos de su carga de trabajo. La carga de trabajo debe degradarse de forma estable y seguir llevando a cabo sus funciones críticas para la empresa durante la activación de un recurso de emergencia. Para obtener más información sobre la degradación estable, consulte [REL05-BP01 Implementación de una degradación estable para transformar las dependencias estrictas en flexibles](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
**Patrones comunes de uso no recomendados:**
+ El fallo de las dependencias no críticas repercute en la disponibilidad de su carga de trabajo principal.
+ No probar o verificar el comportamiento de los componentes críticos durante el deterioro de los componentes no críticos.
+ No definir criterios claros y deterministas para la activación o desactivación de un recurso de emergencia.
**Beneficios de establecer esta práctica recomendada:** la implementación de recursos de emergencia puede mejorar la disponibilidad de los componentes críticos de su carga de trabajo al proporcionar a sus solucionadores procesos establecidos para responder a picos inesperados de demanda o fallos de dependencias no críticas.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
+ Identifique los componentes críticos de su carga de trabajo.
+ Diseñe y cree los componentes críticos de su carga de trabajo para que resistan los fallos de los componentes no críticos.
+ Haga pruebas para validar el comportamiento de sus componentes críticos durante el fallo de los componentes no críticos.
+ Defina y supervise las métricas o los factores desencadenantes relevantes para iniciar los procedimientos de recursos de emergencia.
+ Defina los procedimientos (manuales o automáticos) que componen el recurso de emergencia.
### Pasos para la implementación
+ Identifique los componentes críticos para la empresa en su carga de trabajo.
+ Cada componente técnico de su carga de trabajo debe asignarse a su función empresarial relevante y clasificarse como crítico o no crítico. Para ver ejemplos de funciones críticas y no críticas de Amazon, consulte [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering).
+ Se trata de una decisión tanto técnica como empresarial, y varía según la organización y la carga de trabajo.
+ Diseñe y cree los componentes críticos de su carga de trabajo para que resistan los fallos de los componentes no críticos.
+ Durante el análisis de dependencias, tenga en cuenta todos los modos de fallo potenciales y verifique que sus mecanismos de recursos de emergencia proporcionan la funcionalidad crítica a los componentes descendentes.
+ Haga pruebas para validar el comportamiento de sus componentes críticos durante la activación de sus recursos de emergencia.
+ Evite el comportamiento bimodal. Para obtener más información, consulte [REL11-BP05 Uso de la estabilidad estática para evitar el comportamiento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html).
+ Defina, supervise y alerte sobre las métricas relevantes para iniciar el procedimiento del recurso de emergencia.
+ Encontrar las métricas adecuadas para supervisar depende de su carga de trabajo. Algunos ejemplos de métricas son la latencia o el número de solicitudes fallidas a una dependencia.
+ Defina los procedimientos manuales o automáticos que componen el recurso de emergencia.
+ Esto puede incluir mecanismos como el [desbordamiento de carga](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/), la [limitación de solicitudes](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html) o la implementación de una [degradación estable](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html).
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL05-BP01 Implementación de una degradación estable para transformar las dependencias estrictas en flexibles](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_graceful_degradation.html)
+ [REL05-BP02 Limitación de las solicitudes](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_mitigate_interaction_failure_throttle_requests.html)
+ [REL11-BP05 Uso de la estabilidad estática para evitar el comportamiento bimodal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html)
**Documentos relacionados:**
+ [ Automatización de implementaciones seguras y sin intervención ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/)
+ [Any Day Can Be Prime Day: How Amazon.com Search Uses Chaos Engineering to Handle Over 84K Requests Per Second](https://community.aws/posts/how-search-uses-chaos-engineering)
**Videos relacionados:**
+ [AWS re:Invent 2020: Reliability, consistency, and confidence through immutability](https://www.youtube.com/watch?v=jUSYnRztttY)