Proteger una base de datos ante picos de tráfico es uno de los retos más frecuentes en arquitecturas modernas. En esta práctica se completa la funcionalidad para agregar likes de forma asíncrona usando AWS Lambda, SQS y DynamoDB, logrando una solución desacoplada, resiliente y lista para producción.
¿Cómo funciona la lambda que suma likes uno a uno?
El punto de partida es una función Lambda que se conecta a DynamoDB mediante el SDK de AWS [0:36]. Igual que en las lambdas anteriores, se requiere el cliente de DynamoDB porque allí se almacena cada like.
Dentro del handler, la lógica es directa:
- Se extrae el body del request tipo POST [1:04].
- Del body se obtiene un ID que corresponde a un registro ya existente en la base de datos [1:15].
- Se usa una update expression de DynamoDB para incrementar el campo
likes en una unidad [1:25].
DynamoDB permite ejecutar lógica con update expressions, lo que significa que el motor de base de datos se encarga de la operación aritmética sin necesidad de leer, sumar y escribir desde el código. Esto reduce trabajo y minimiza riesgos de condiciones de carrera.
Adicionalmente, se incluye una función sleep de cuatro segundos [0:50] después de cada actualización. Este retardo no es necesario en producción; su propósito es visualizar cómo los likes se van sumando progresivamente, dado que en la clase anterior se restringió la cola a ejecutar una única lambda concurrente [1:56].
¿Qué ajustes previos se corrigieron antes del despliegue?
Antes de escribir la lógica principal, se resolvieron dos problemas:
- Un bug en Serverless Framework hacía que los archivos listados en
.gitignore no se excluyeran del empaquetado, provocando que las lambdas pesaran mucho más de lo esperado [0:14]. La solución fue eliminar el archivo innecesario.
- El mensaje devuelto por la cola no estaba en formato JSON válido porque faltaba una comilla en el código [0:28]. Corregir ese carácter solucionó el problema.
Tras el redespliegue con serverless deploy, las lambdas volvieron a su tamaño original y la salida del framework no mostró cambios estructurales, solo la actualización del código [2:10].
¿Cómo se prueba la funcionalidad de likes asíncronos?
La prueba se realizó desde Postman siguiendo estos pasos:
- Se copió la URL del endpoint POST que envía mensajes a la cola SQS [2:22].
- Se consultó un usuario existente con un GET para obtener su ID [2:33].
- Se armó el body del POST con ese ID y se envió el mensaje.
Al hacer un nuevo GET al usuario, este ya mostraba un like [2:55]. Los tiempos de respuesta del POST son muy cortos porque no hay cómputo pesado: el mensaje queda directamente encolado y la lambda se encarga del procesamiento por separado [3:05].
¿Qué sucede con múltiples likes simultáneos?
Para simular un escenario de alta demanda, se enviaron muchos mensajes consecutivos al endpoint [3:28]. Desde la consola de DynamoDB se pudo observar cómo el campo likes iba incrementándose cada cuatro segundos: primero siete, luego ocho, y así sucesivamente [3:45].
Este comportamiento demuestra el concepto de desacoplamiento: el backend no necesita absorber todos los likes de manera inmediata. La cola SQS los almacena y la lambda los procesa a su propio ritmo.
¿Por qué esta arquitectura es más resiliente?
Los beneficios principales de este patrón son claros:
- La base de datos nunca se satura ante ráfagas de tráfico [3:57].
- El procesamiento asíncrono con concurrencia reservada evita que múltiples lambdas compitan por el mismo recurso.
- La aplicación sigue buenas prácticas de arquitectura orientada a eventos, haciéndola mucho más resiliente ante picos de carga.
Si implementaste esta funcionalidad, comparte tu experiencia y cuéntanos cómo adaptarías este patrón a otros casos de uso en tus proyectos.
