Patrón síncrono en arquitecturas serverless con Platzi Wallet

Clase 16 de 27Curso de Introducción a la Nube

Contenido del curso

Resumen

Comprender cómo se conectan los componentes de una arquitectura serverless es fundamental para diseñar aplicaciones modernas en la nube. A través de un ejemplo práctico de consulta de saldo en una billetera virtual, es posible visualizar el flujo completo desde que un usuario genera una solicitud hasta que recibe su respuesta, todo sin administrar servidores.

¿Cómo funciona el patrón request and response en serverless?

El patrón request and response describe un flujo donde un cliente envía una solicitud a un servicio y espera recibir una respuesta. En el ejemplo planteado, el usuario Carlos abre su aplicación móvil llamada Platsi Wallet y solicita consultar su saldo [0:25]. Este patrón es síncrono, lo que significa que el cliente permanece esperando hasta obtener la información solicitada antes de continuar con cualquier otra acción.

La diferencia con un patrón asíncrono es clara: en el caso asíncrono, como solicitar un certificado para pago de impuestos, no es necesario quedarse esperando la respuesta en tiempo real. El resultado puede llegar después, por ejemplo al correo electrónico, posiblemente a través de una cola de mensajes [3:15]. En cambio, en el flujo síncrono de consulta de saldo, cada componente espera la respuesta del siguiente para poder continuar.

¿Qué componentes serverless intervienen en la consulta de saldo?

El flujo involucra tres componentes principales que trabajan en cadena:

  • API Gateway: es la puerta de enlace que recibe la solicitud del usuario a través de internet. Funciona como un API REST que identifica qué operación se está pidiendo y la redirige al componente adecuado [1:20].
  • Función (Function): recibe los datos del API Gateway, como el ID del usuario y el tipo de consulta. Su responsabilidad es ejecutar la lógica de negocio, en este caso, ir a buscar el saldo correspondiente [1:45].
  • Datastore: es la base de datos donde se almacena la información. En el ejemplo se trata de una base de datos no relacional que recibe la consulta de la función, busca el registro del usuario y devuelve el dato solicitado [2:10].

¿Cuál es el flujo completo paso a paso?

El recorrido de la información sigue un camino claro y ordenado:

  • Carlos se autentica en la aplicación y presiona "consultar saldo".
  • La aplicación genera un evento que viaja por internet hasta el API Gateway.
  • El API Gateway recibe la solicitud y la pasa a la función con los parámetros necesarios.
  • La función consulta el Datastore buscando el saldo asociado al ID de Carlos.
  • El Datastore encuentra el dato y se lo devuelve a la función.
  • La función entrega el resultado al API Gateway.
  • El API Gateway responde al usuario: "tienes cien dólares" [2:40].

Cada paso depende del anterior, lo que confirma la naturaleza síncrona del patrón. No hay colas intermedias ni procesamiento diferido.

¿Por qué es importante distinguir entre síncrono y asíncrono?

Elegir entre un patrón síncrono o asíncrono impacta directamente en la experiencia del usuario y en el diseño de la arquitectura. Cuando el usuario necesita una respuesta inmediata, como ver su saldo antes de realizar un pago, el flujo síncrono es la opción correcta. Cuando la respuesta puede demorar y no bloquea al usuario, el patrón asíncrono permite mayor eficiencia al liberar recursos mientras se procesa la solicitud en segundo plano.

¿Qué más se puede construir con componentes serverless?

El ejemplo presentado es solo un caso de uso de los muchos posibles. Combinando API Gateways, funciones y datastores se pueden construir aplicaciones completas basadas en serverless [4:20]. Existen múltiples patrones arquitectónicos que aprovechan estos mismos componentes de formas distintas, adaptándose a diferentes necesidades como procesamiento de eventos, notificaciones o flujos de trabajo complejos.

Un recurso recomendado para profundizar es el libro Learning Serverless de O'Reilly [4:50], que cubre patrones, teoría y casos prácticos para quienes buscan dominar este paradigma.

¿Conoces algún otro patrón serverless que hayas implementado o te gustaría explorar? Comparte tu experiencia en los comentarios.