# REL04-BP01 Identificar qué tipo de sistema distribuido se necesita
<a name="rel_prevent_interaction_failure_identify"></a>

 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
<a name="implementation-guidance"></a>
+  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
<a name="resources"></a>

 **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)