# REL 4 ¿Cómo diseña las interacciones en un sistema distribuido para evitar errores?
Los sistemas distribuidos dependen de las redes de comunicaciones para interconectar componentes, como servidores o servicios. Su carga de trabajo debe funcionar de manera fiable aunque se pierdan datos o haya latencia en estas redes. Los componentes del sistema distribuido deben funcionar de forma que no repercutan negativamente en otros componentes ni en la carga de trabajo. Estas prácticas recomendadas evitan que se produzcan errores y mejoran el tiempo medio entre errores (MTBF).
**Topics**
+ [REL04-BP01 Identificar qué tipo de sistema distribuido se necesita](rel_prevent_interaction_failure_identify.md)
+ [REL04-BP02 Implementar dependencias con acoplamiento flexible](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL04-BP03 Realizar un trabajo constante](rel_prevent_interaction_failure_constant_work.md)
+ [REL04-BP04 Hacer que todas las respuestas sean idempotentes](rel_prevent_interaction_failure_idempotent.md)
# REL04-BP01 Identificar qué tipo de sistema distribuido se necesita
Los sistemas distribuidos en tiempo real estrictos requieren que las respuestas se proporcionen de forma sincrónica y rápidamente, mientras que los sistemas en tiempo real laxos cuentan con un plazo de tiempo más generoso, que se mide en minutos o más, para proporcionar una respuesta. Los sistemas sin conexión gestionan las respuestas a través del procesamiento por lotes o asincrónico. Los sistemas distribuidos en tiempo real estrictos tienen los requisitos de fiabilidad más exigentes.
Los desafíos más complicados [relacionados con los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/) giran en torno a los sistemas distribuidos en tiempo real, conocidos también como servicios de solicitud/respuesta. Lo que hace que sean tan difíciles es que las solicitudes llegan de forma impredecible y las respuestas deben emitirse rápidamente (por ejemplo, si el cliente está esperando una respuesta de forma activa). Entre algunos ejemplos se incluyen los servidores web de front-end, la canalización de pedidos, las transacciones con tarjetas de crédito, todas las API de AWS y la telefonía.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Identifique qué tipo de sistema distribuido se necesita. Entre los problemas de los sistemas distribuidos se incluyen la latencia, el escalado, conocer las API de red, la serialización y deserialización de los datos, y la complejidad de algoritmos como Paxos. A medida que los sistemas crecen y se hacen más distribuidos, los casos extremos teóricos se convierten en sucesos habituales.
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ Los sistemas distribuidos en tiempo real estrictos requieren que las respuestas se proporcionen de forma sincrónica y rápidamente.
+ Los sistemas en tiempo real laxos cuentan con un plazo más generoso, que se mide en minutos o más, para proporcionar una respuesta.
+ Los sistemas sin conexión gestionan las respuestas a través del procesamiento por lotes o asincrónico.
+ Los sistemas distribuidos en tiempo real estrictos tienen los requisitos de fiabilidad más exigentes.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Videos relacionados:**
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Bucles cerrados y mentes abiertas: cómo asumir el control de los sistemas grandes y pequeños ARC337 (incluye acoplamiento flexible, trabajo constante y estabilidad estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP02 Implementar dependencias con acoplamiento flexible
Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento flexible. El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
Si un cambio en un componente obliga a otros componentes que dependen de él a aplicar ese cambio, entonces los componentes tienen un *acoplamiento* estricto. *El acoplamiento* flexible elimina esta dependencia, de forma que los componentes dependientes solo necesitan conocer la nueva versión de la interfaz publicada. Al implementar un acoplamiento flexible entre dependencias, se aíslan los fallos que se puedan producir en una, de modo que no afecten a la otra.
El acoplamiento flexible le permite añadir código o funciones adicionales a un componente mientras se reduce al mínimo el riesgo para los componentes que dependen de él. Además, se mejora la escalabilidad, ya que puede escalar horizontalmente o incluso cambiar la implementación subyacente de la dependencia.
Para mejorar aún más la resiliencia mediante el acoplamiento flexible, haga que las interacciones entre componentes sean asíncronas siempre que sea posible. Este modelo es adecuado para cualquier interacción que no necesite una respuesta inmediata y en la que baste con el reconocimiento de que una solicitud se ha registrado. Consta de un componente que genera eventos y de otro que los consume. Ambos componentes no se integran mediante una interacción directa de punto a punto, sino que normalmente emplean una capa de almacenamiento duradera intermedia, como una cola SQS o una plataforma de retransmisión de datos como Amazon Kinesis o AWS Step Functions.
![\[Diagrama que muestra el acoplamiento flexible de dependencias como sistemas de colas y equilibradores de carga\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/loosely-coupled-dependencies.png)
Las colas de Amazon SQS y los equilibradores de carga elásticos son solo dos formas de añadir una capa intermedia para el acoplamiento flexible. Las arquitecturas basadas en eventos también pueden integrarse en Nube de AWS utilizando Amazon EventBridge, lo que puede abstraer a los clientes (productores de eventos) de los servicios en los que confían (consumidores de eventos). Amazon Simple Notification Service (Amazon SNS) es una solución eficaz cuando se necesita una mensajería de alto rendimiento, basada en push y de varios a varios. Utilizando temas de Amazon SNS, los sistemas de tu publicador pueden repartir mensajes por una gran cantidad de puntos de conexión de suscriptores para su procesamiento paralelo.
Aunque las colas ofrecen varias ventajas, en la mayoría de sistemas inflexibles en tiempo real, las solicitudes que superan un umbral temporal (que suele ser de segundos) se consideran obsoletas (el cliente ha desistido y ya no espera una respuesta), por lo que no se procesan. De esta manera, se pueden procesar las solicitudes más recientes (y probablemente aún válidas) en su lugar.
**Patrones de uso no recomendados comunes:**
+ Implementar un singleton como parte de una carga de trabajo
+ Invocar directamente las API entre capas de la carga de trabajo sin la capacidad de conmutar por error ni procesar asincrónicamente la solicitud
**Beneficios de establecer esta práctica recomendada:** El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad. Un error en un componente está aislado de los demás componentes.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto
## Guía para la implementación
+ Implementar dependencias con acoplamiento flexible Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento flexible. El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
+ Amazon EventBridge le permite crear arquitecturas basadas en eventos, que tienen acoplamiento flexible y son arquitecturas distribuidas.
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ Si un cambio en un componente obliga a otros componentes que dependen de él a aplicar ese cambio, entonces los componentes tienen un acoplamiento estricto. El acoplamiento flexible elimina esta dependencia, de forma que los componentes dependientes solo necesitan conocer la nueva versión de la interfaz publicada.
+ Haga que las interacciones de los componentes sean asincrónicas siempre que sea posible. Este modelo es adecuado para cualquier interacción que no necesite una respuesta inmediata y en la que baste con el reconocimiento de que una solicitud se ha registrado.
+ [AWS re:Invent 2019: Aplicaciones escalables basadas en eventos sin servidor mediante Amazon SQS y Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
## Recursos
**Documentos relacionados:**
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [¿Qué es Amazon Simple Queue Service?](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/welcome.html)
**Vídeos relacionados:**
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Bucles cerrados y mentes abiertas: cómo asumir el control de los sistemas grandes y pequeños ARC337 (incluye acoplamiento flexible, trabajo constante y estabilidad estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://youtu.be/h46IquqjF3E)
+ [AWS re:Invent 2019: Aplicaciones escalables basadas en eventos sin servidor mediante Amazon SQS y Lambda (API304)](https://youtu.be/2rikdPIFc_Q)
# REL04-BP03 Realizar un trabajo constante
Los sistemas pueden producir error cuando hay cambios rápidos grandes en la carga. Por ejemplo, si la carga de trabajo está realizando una comprobación de estado que supervisa el estado de miles de servidores, debería enviar siempre una carga del mismo tamaño (una instantánea completa del estado actual). Si no hay errores en ningún servidor, o hay errores en todos ellos, el sistema de comprobación de estado estará haciendo un trabajo constante sin rápidos cambios de gran tamaño.
Por ejemplo, si el sistema de comprobación de estado supervisa 100 000 servidores, la carga contenida en él es nominal con un porcentaje de errores del servidor normalmente bajo. Sin embargo, si un evento importante deja a la mitad de esos servidores en mal estado, el sistema de comprobación de estado se sobrecargaría intentando actualizar los sistemas de notificación y comunicar el estado a sus clientes. Por ello, el sistema de comprobación de estado debería enviar cada vez la instantánea completa del estado actual. 100 000 estados de servidor, cada uno representado por un bit, solo constituiría una carga de 12,5 KB. Si no hay errores en ningún servidor, o hay errores en todos ellos, el sistema de comprobación de estado estará haciendo un trabajo constante y los cambios rápidos de gran tamaño no pondrán en peligro la estabilidad del sistema. En realidad, así es como Amazon Route 53 gestiona las comprobaciones de estado de los puntos de conexión (como las direcciones IP) para determinar cómo se enruta a los usuarios finales.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Bajo
## Guía para la implementación
+ Realice un trabajo para que los sistemas no tengan errores cuando hay cambios grandes y rápidos en la carga.
+ Implemente dependencias con acoplamiento flexible. Las dependencias, como los sistemas de colas, los sistemas de transmisión, los flujos de trabajo y los equilibradores de carga, tienen un acoplamiento flexible. El acoplamiento flexible ayuda a aislar el comportamiento de un componente de otros componentes que dependen de él, lo que aumenta la resiliencia y la agilidad.
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work) (Cerrar los bucles y abrir las mentes: cómo tomar el control de los sistemas, grandes y pequeños ARC337 [incluye trabajo constante])](https://youtu.be/O8xLxNje30M?t=2482)
+ En el ejemplo de una sistema de comprobación de estado que supervisa 100 000 servidores, diseñe las cargas de trabajo de forma que los tamaños de la carga útil sean iguales independientemente del número de éxitos o fracasos.
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Vídeos relacionados:**
+ [AWS New York Summit 2019: Intro to Event-driven Architectures and Amazon EventBridge (Introducción a las arquitecturas basadas en eventos y Amazon EventBridge) (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes constant work) (Cerrar los bucles y abrir las mentes: cómo asumir el control de los sistemas grandes y pequeños ARC337 [incluye trabajo constante])](https://youtu.be/O8xLxNje30M?t=2482)
+ [AWS re:Invent 2018: Close Loops and Opening Minds: How to Take Control of Systems, Big and Small ARC337 (includes loose coupling, constant work, static stability) (Cerrar los bucles y abrir las mentes: cómo asumir el control de los sistemas grandes y pequeños ARC337 [incluye acoplamiento flexible, trabajo constante y estabilidad estática])](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Moving to event-driven architectures (Optar por arquitecturas basadas en eventos) (SVS308)](https://youtu.be/h46IquqjF3E)
# REL04-BP04 Hacer que todas las respuestas sean idempotentes
Un servicio idempotente promete que cada solicitud se completará una y solo una vez, de tal forma que realizar varias solicitudes idénticas tiene el mismo efecto que realizar una sola solicitud. Un servicio idempotente permite que un cliente implemente fácilmente los reintentos sin el temor de que una solicitud se procese erróneamente varias veces. Para ello, los clientes pueden usar solicitudes de API con un token de idempotencia: se utiliza el mismo token siempre que se repite la solicitud. Una API de servicio idempotente usa el token para devolver una respuesta idéntica a la que se devolvió por primera vez cuando se completó la solicitud.
En un sistema distribuido, es fácil llevar a cabo una acción una vez como máximo (el cliente realiza solo una solicitud) o al menos una vez (sigue realizando la solicitud hasta que el cliente obtiene una confirmación del éxito). Sin embargo, es difícil garantizar que una acción es idempotente, lo que significa que se lleva a cabo *exactamente* una vez, de modo que realizar varias solicitudes idénticas tiene el mismo efecto que realizar una sola solicitud. Al usar tokens de idempotencia en las API, los servicios pueden recibir una solicitud de migración una o más veces sin crear registros duplicados ni efectos secundarios.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Mediana
## Guía para la implementación
+ Haga que todas las respuestas sean idempotentes. Un servicio idempotente promete que cada solicitud se completará una y solo una vez, de tal forma que realizar varias solicitudes idénticas tiene el mismo efecto que realizar una sola solicitud.
+ Los clientes pueden usar solicitudes de API con un token de idempotencia: se utiliza el mismo token siempre que se repite la solicitud. Una API de servicio idempotente usa el token para devolver una respuesta idéntica a la que se devolvió por primera vez cuando se completó la solicitud.
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
## Recursos
**Documentos relacionados:**
+ [Amazon EC2: garantizar la idempotencia](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html)
+ [La Amazon Builders' Library: Desafíos de los sistemas distribuidos](https://aws.amazon.com/builders-library/challenges-with-distributed-systems/)
+ [La Amazon Builders' Library: Fiabilidad, trabajo constante y una buena taza de café](https://aws.amazon.com/builders-library/reliability-and-constant-work/)
**Videos relacionados:**
+ [Cumbre de AWS en Nueva York 2019: Introducción a las arquitecturas basadas en eventos y Amazon EventBridge (MAD205)](https://youtu.be/tvELVa9D9qU)
+ [AWS re:Invent 2018: Bucles cerrados y mentes abiertas: cómo asumir el control de los sistemas grandes y pequeños ARC337 (incluye acoplamiento flexible, trabajo constante y estabilidad estática)](https://youtu.be/O8xLxNje30M)
+ [AWS re:Invent 2019: Optar por arquitecturas basadas en eventos (SVS308)](https://youtu.be/h46IquqjF3E)