Una arquitectura serverless combina servicios gestionados como API Gateway, funciones y bases de datos para responder solicitudes sin administrar servidores. Aquí verás cómo encajan estos componentes en un caso real de Platzi Wallet, ideal si estás aprendiendo cloud computing y quieres entender el flujo completo de un request and response síncrono.

¿Qué es un patrón request and response síncrono en serverless?

El patrón request and response describe la conversación entre un cliente y un servicio: tú haces una solicitud y esperas la respuesta antes de continuar. Cuando ese intercambio es síncrono, el sistema mantiene la conexión abierta hasta que llega el dato.

Imagina que abres tu app de Platzi Wallet y tocas consultar saldo. Ese gesto dispara un evento que viaja por internet hasta el backend. Tú no sigues navegando, te quedas esperando ver cuánto dinero tienes. Eso es síncrono.

¿Qué diferencia hay entre síncrono y asíncrono en serverless? En síncrono, el cliente espera la respuesta inmediata, como al consultar un saldo. En asíncrono, el cliente envía la solicitud y recibe la respuesta después por otro canal, como un correo con un certificado de impuestos.

¿Cómo se conectan API Gateway, función y data store?

El flujo del ejemplo de Platzi Wallet usa tres piezas serverless trabajando en cadena. Cada una tiene una responsabilidad clara y se comunica con la siguiente mediante eventos.

Carlos abre su aplicación, se autentica y pulsa consultar saldo. Ese evento llega primero al API Gateway, que actúa como puerta de enlace. El API recibe la solicitud con el ID de Carlos y la reenvía a una función.

La función toma el dato, va al data store, que en este caso es una base de datos no relacional, y consulta por el ID de Carlos. Cuando encuentra el saldo, devuelve la información a la función, la función al API y el API al celular de Carlos. Resultado: Carlos ve sus 100 dólares y puede hacer un pago.

¿Qué hace cada componente en el flujo?

• API Gateway: recibe la solicitud HTTP del cliente y la enruta hacia la función correspondiente. Es el punto de entrada del sistema.
• Función: ejecuta la lógica de negocio. Recibe parámetros como el ID del usuario, consulta la base de datos y procesa la respuesta.
• Data store: almacena la información. Aquí es una base de datos no relacional optimizada para búsquedas rápidas por clave.

Esa separación de responsabilidades es lo que hace escalable a una arquitectura serverless. Cada pieza se ejecuta solo cuando se necesita y se cobra por uso.

¿Por qué importa entender este patrón si trabajas en cloud?

Saber identificar cuándo usar un patrón síncrono te ayuda a tomar mejores decisiones de diseño. No todo evento necesita esperar respuesta inmediata, y forzarlo puede saturar tus funciones o aumentar costos.

En una consulta de saldo tiene sentido ser síncrono porque el usuario necesita el dato al instante. Pero si Carlos pidiera un certificado de impuestos, lo lógico sería un flujo asíncrono con una cola de mensajes y entrega posterior por correo. Ese criterio define la calidad de tu arquitectura.

¿Cuándo conviene usar una arquitectura serverless síncrona? Cuando la respuesta es inmediata, breve y el usuario espera el resultado en pantalla. Consultas de saldo, búsquedas o validaciones rápidas son casos típicos.

¿Qué otros patrones serverless puedes explorar?

El ejemplo de Platzi Wallet es solo una combinación posible. Puedes construir aplicaciones completas mezclando colas, eventos asíncronos, procesamiento por lotes, streaming de datos o flujos orquestados con máquinas de estado.

Un buen punto de partida para profundizar es el libro Learning Serverless de O'Reilly. Cubre teoría, patrones de diseño y casos de uso reales que te dan contexto más allá de un solo ejemplo.

El reto ahora es tuyo: piensa en una funcionalidad de tu propia app o proyecto y dibuja qué componentes serverless usarías para construirla. ¿Qué patrón se te ocurre primero? Cuéntalo en los comentarios.