Procesar likes de forma asíncrona con AWS Lambda y SQS te permite escalar funcionalidades sociales sin saturar la base de datos. Aquí verás cómo conectar la lógica final que suma likes uno a uno desde una cola, protegiendo DynamoDB y manteniendo tu backend resiliente bajo picos de tráfico.

Cómo se construye la lambda que suma likes en DynamoDB

La pieza que faltaba en la arquitectura es la función que consume los mensajes encolados y actualiza el contador en la base de datos. Toda la lógica vive en un solo handler que recibe el evento, extrae la información y delega el cálculo al motor de DynamoDB.

Qué necesita el handler para actualizar un registro

El flujo arranca importando el SDK de Amazon para obtener el cliente de DynamoDB, igual que en las lambdas anteriores. A partir de ahí, el código extrae el body del request enviado por POST y obtiene el ID del usuario al que se le sumará el like [01:30].

Ese ID corresponde a un registro existente en la tabla. La lambda ejecuta un update sobre ese ítem y devuelve el control una vez confirmada la operación.

¿Qué hace exactamente la lambda al recibir un mensaje? Lee el ID del usuario desde el body, ejecuta un update en DynamoDB que incrementa el campo likes en uno y espera antes de procesar el siguiente mensaje de la cola.

Por qué usar expresiones de DynamoDB para sumar

En lugar de leer el valor actual, sumarle uno y volver a escribirlo, DynamoDB permite delegar esa operación al motor de base de datos mediante update expressions. Le indicas que agregue una cantidad fija al campo likes y el servicio se encarga del resto [02:05].

Esto evita condiciones de carrera, reduce código y aprovecha la potencia nativa del servicio.

Por qué se agrega un sleep de cuatro segundos en la lambda

Dentro del handler aparece una función sleep que recibe milisegundos como argumento y pausa la ejecución. No es parte de la lógica de negocio: se incluye únicamente con fines didácticos para visualizar cómo los likes se van sumando con el paso del tiempo [01:15].

Como en la clase anterior se restringió la concurrencia a una única lambda en paralelo, cada mensaje se procesa de forma secuencial. Aproximadamente cada cuatro segundos se suma un like, lo que permite ver el efecto en vivo desde la consola de DynamoDB.

¿Es obligatorio el sleep en producción? No. En un entorno real lo eliminas para que la lambda procese los mensajes lo más rápido posible. Solo sirve aquí para observar el desacople en tiempo real.

Cómo se prueba el flujo completo desde Postman

Una vez actualizada la lambda con Serverless Framework, basta con redesplegarla y validar que todo el circuito funcione punto a punto. La salida del despliegue muestra que las lambdas vuelven a su tamaño original, ya que se eliminó un archivo innecesario que se estaba empaquetando por un bug del framework relacionado con el gitignore [00:25].

Qué pasos seguir para enviar el primer like

El proceso para probar la funcionalidad es directo:

1. Copiar la URL del endpoint POST que encola mensajes.
2. Hacer un GET a un usuario existente para obtener un ID válido.
3. Armar el body del POST con ese ID y enviarlo a la cola.
4. Hacer un GET nuevamente al usuario para confirmar que el campo likes aumentó.

Al repetir el envío, notas que los tiempos de respuesta son muy cortos. Eso ocurre porque el endpoint no procesa el like: simplemente encola el mensaje y devuelve, mientras la lambda trabaja en segundo plano [03:30].

Cómo se ve el desacople en DynamoDB

Abriendo la tabla en la consola de DynamoDB y enviando varios mensajes seguidos desde Postman, puedes ver cómo el contador sube de forma escalonada. Después de cuatro segundos van siete likes, luego ocho, y así sucesivamente.

Este es el punto clave: aunque envíes una ráfaga de requests simulando a una persona muy popular en una red social, la base de datos nunca recibe todo el tráfico de golpe. La cola actúa como amortiguador y la lambda consume a su propio ritmo.

Qué ventajas reales aporta esta arquitectura desacoplada

Desacoplar la suma de likes mediante una cola tiene beneficios concretos para cualquier backend que enfrente tráfico variable:

• La base de datos queda protegida frente a picos de requests.
• El endpoint público responde en milisegundos porque solo encola.
• La lambda procesa a un ritmo controlado y predecible.
• El sistema gana resiliencia y aplica mejores prácticas de arquitectura.

Con esto cierras una funcionalidad que combina API Gateway, SQS, Lambda y DynamoDB en un patrón reutilizable para likes, comentarios, notificaciones o cualquier acción social que deba escalar sin tumbar tu backend. ¿Qué otra funcionalidad de tu app pondrías detrás de una cola? Cuéntalo en los comentarios.