# 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/)