Diseñar una arquitectura serverless implica conocer las piezas que la componen y cuándo usar cada una. Aquí mapeamos los componentes típicos de una aplicación serverless con ejemplos prácticos, pensando en casos como Platzi Wallet, para que puedas decidir qué encaja en tu próximo proyecto en la nube.

¿Qué es un stream y cuándo usarlo en tiempo real?

Los streams aparecen en casi todo proyecto de datos donde la palabra clave es real time. La idea es simple: usar un evento o acción apenas ocurre, sin esperar.

Un stream es una secuencia de eventos, mensajes o datos que se procesan una vez ocurren. En Platzi Wallet, cuando un usuario hace un pago, ese log viaja al stream y de ahí a un consumidor, por ejemplo un dashboard de visualización para el equipo de growth o marketing.

¿Qué es real time en arquitectura serverless? Es la capacidad de procesar y usar un evento apenas ocurre, con la menor latencia posible entre la acción del usuario y el consumo del dato.

Imagina Platzi Wallet con 10 millones de usuarios generando millones de logs por minuto entre pagos, transferencias y compras en Amazon o Netflix. El stream recibe cientos de millones de eventos en paralelo y los reenvía a un dashboard para graficar pagos y retiros en vivo [3:00].

La capacidad del stream se mide en shards, su unidad de medida, y en los cloud providers suele ser un servicio totalmente serverless: cero administración de servidores.

¿Cómo funcionan las colas para desacoplar componentes?

Una cola es un método para retrasar el trabajo y desacoplar componentes. Piensa en un banco: las personas no se amontonan sobre el cajero, se forman por orden de llegada para no saturarlo. Lo mismo pasa en software [4:30].

Vuelve a Platzi Wallet. Supón que 100.000 usuarios piden al tiempo un certificado para declaración de impuestos. El microservicio escala, pero colapsa por la presión simultánea. ¿La solución? Encolar.

• Todas las solicitudes entran a la cola y esperan su turno.
• La aplicación las procesa al ritmo que puede sostener.
• Todos los usuarios reciben respuesta sin tumbar el servicio.

La cola desacopla la arquitectura y evita la saturación, sin importar el volumen del spike.

¿Qué componentes de almacenamiento y acceso necesita una app serverless?

Más allá de streams y colas, una arquitectura serverless típica combina almacenamiento, puertas de entrada, identidad y consultas. Cada pieza tiene un rol claro.

Buckets y data stores: ¿dónde guardo la información?

Un bucket es una estructura para almacenar objetos, como las fotos de perfil que cada usuario sube en Platzi Wallet. Su costo se basa en la cantidad de información almacenada y en la cantidad de requests que recibe.

Un data store, en cambio, es un espacio para almacenar información estructurada. Aquí entran las bases de datos no relacionales:

• Llave-valor.
• En memoria.
• Documentales.
• Por grafos.

¿Cuál es la diferencia entre un bucket y un data store? Un bucket guarda objetos como imágenes o archivos completos. Un data store guarda registros consultables, típicamente en bases no relacionales optimizadas para acceso rápido.

APIs e identity services: ¿cómo entran y se autentican los usuarios?

Un API, abreviación de Application Programming Interface, es la puerta de entrada a tu aplicación y permite comunicar dos componentes de software bajo definiciones y protocolos comunes. En los cloud providers tienes API REST, HTTPS, WebSocket y GraphQL, todas como servicios serverless.

Los identity services resuelven dos cosas distintas: autenticación y autorización. La analogía es directa: si tocan la puerta de tu apartamento y dicen "soy el vecino del 201", lo autenticas porque sabes quién es. Otra cosa es si lo autorizas a entrar [9:00].

En Platzi Wallet pasa igual. Te registras y la app te autentica como Carlos Zambrano, pero no te autoriza a hacer un pago hasta que registres una tarjeta o agregues saldo.

Motores de consulta y balanceadores: ¿cómo consulto datos y distribuyo carga?

Los motores de consulta, basados en software open source como Presto, ejecutan queries SQL contra múltiples fuentes: almacenamiento por objetos, bases no relacionales (llave-valor, en memoria, documentales) y bases relacionales. Solo pagas por la cantidad de data escaneada, lo que los hace eficientes para análisis distribuidos.

Los balanceadores de carga distribuyen el tráfico para que ningún componente colapse. Hay dos tipos clave:

• Balanceador de aplicaciones: trabaja en la capa 7 del modelo OSI, balancea HTTP y HTTPS, foco total en aplicación.
• Balanceador de red: trabaja en las capas 3 y 4 del modelo OSI, balancea tráfico IP, UDP y TCP.

En Platzi Wallet, el balanceador recibe los requests y los distribuye entre zonas de disponibilidad para garantizar que la aplicación no colapse bajo carga.

El reto: dibuja tu arquitectura serverless

Piensa en una aplicación que vayas a construir, migrar o llevar a la nube. Define qué componentes usarías y por qué:

1. ¿Necesitas procesar eventos en tiempo real? Suma un stream.
2. ¿Tienes picos de solicitudes que pueden saturar un microservicio? Mete una cola.
3. ¿Vas a guardar archivos de usuario? Define un bucket.
4. ¿Cómo expones la app? API REST, GraphQL o WebSocket.
5. ¿Cómo autenticas y autorizas? Suma un identity service.
6. ¿Vas a consultar varias fuentes? Considera un motor de consultas.
7. ¿Cómo distribuyes la carga? Balanceador de aplicaciones o de red.

Dibuja un borrador de esa arquitectura usando estos bloques serverless y comparte en los comentarios qué componentes elegiste y por qué.