Proteger la base de datos y controlar la concurrencia son dos desafíos frecuentes cuando una aplicación recibe ráfagas de peticiones. En lugar de dejar que cada request impacte directamente la base de datos, existe un patrón que coloca una cola de mensajes entre el endpoint público y la función que ejecuta la escritura. El resultado: un sistema resiliente, desacoplado y que procesa el trabajo a su propio ritmo.
¿Cómo funciona la arquitectura API Gateway, SQS y Lambda?
El caso de uso planteado consiste en sumar likes a usuarios de forma asíncrona [0:18]. La idea es que, sin importar cuántos likes lleguen en un instante, la base de datos nunca se sature. Para lograrlo se conectan tres servicios de AWS en cadena:
- API Gateway recibe la petición HTTP del usuario con el ID del destinatario del like.
- SQS (Simple Queue Service) almacena ese mensaje en una cola sin que intervenga ninguna Lambda intermedia [0:48].
- Lambda worker toma los mensajes de la cola y los escribe en la base de datos, uno a uno.
El detalle clave es que API Gateway llama directamente a SQS, sin pasar por una Lambda intermedia [0:42]. Esto reduce latencia, costos y puntos de fallo. El cuerpo del request —con el ID del usuario— queda guardado en la cola hasta que la Lambda lo recoja.
¿Qué es el reserved concurrency y por qué limitar a una sola Lambda?
Si un usuario recibe mil likes en un segundo, Lambda podría crear mil instancias simultáneas para atenderlos [7:28]. Eso derrotaría el propósito de proteger la base de datos. Por eso se configura el reserve concurrency en uno [7:38], garantizando que solo una instancia de la Lambda esté corriendo al mismo tiempo. Los mensajes esperan en la cola y se procesan de manera secuencial, distribuyendo la carga en el tiempo.
Otra configuración importante es el batch size [6:37]. Se establece en uno para que la Lambda digiera un solo mensaje por invocación, manteniendo el control total sobre cada escritura.
¿Cómo se implementa con plugins de Serverless Framework?
En lugar de escribir toda la infraestructura manualmente en el archivo YAML, se aprovechan dos plugins de la comunidad que simplifican enormemente el trabajo [2:36].
Plugin serverless-apigateway-service-proxy
Este plugin permite conectar API Gateway con diferentes servicios de AWS —DynamoDB, EventBridge, SQS— sin código adicional [3:10]. La configuración se coloca en la sección custom del YAML e incluye:
- Un path para la ruta del endpoint.
- El método HTTP (post).
- El nombre de la cola destino.
- Habilitación de CORS para aceptar peticiones desde distintos dominios.
- Mensajes de respuesta personalizados: código 200 cuando el mensaje llega correctamente y mensajes de error en caso contrario [4:16].
Plugin serverless-lift
Este segundo plugin introduce el concepto de constructs [5:48], que permiten crear conjuntos completos de recursos con muy poco código. En la sección constructs del YAML se define un recurso de tipo queue que crea simultáneamente la cola SQS y la Lambda worker asociada [6:08].
Dentro de la configuración del worker se especifica:
- La ruta del handler (
likeUser/handler.likeUser).
- Un package individual para mantener la Lambda ligera [7:10].
- El reserved concurrency en uno.
Para que ambos plugins coincidan, se asigna el mismo nombre a la cola tanto en el proxy de API Gateway como en la propiedad extensions del construct, utilizando la key queueName [8:18].
¿Cómo verificar que la cola y la Lambda funcionan correctamente?
Tras el despliegue con sls deploy, Serverless Framework muestra las nuevas salidas: el endpoint POST separado del resto de rutas, la Lambda worker creada y la URL informativa de la cola [9:20].
Para probar, basta enviar un request POST al nuevo endpoint desde Postman. La cola responde con un código 200 en aproximadamente doscientos milisegundos [10:12], confirmando que recibió el mensaje sin intervención de ninguna Lambda.
La verificación de la Lambda worker se realiza con el comando sls logs -f nombreFuncion [10:28], que muestra los logs directamente en la terminal sin necesidad de abrir CloudWatch. Cada mensaje procesado aparece como una entrada en el registro, confirmando que la Lambda consume la cola correctamente [10:50].
Al enviar múltiples requests rápidamente, los mensajes se acumulan en la cola y la única instancia de Lambda los va procesando con calma, exactamente el comportamiento esperado para proteger la base de datos de escrituras masivas simultáneas.
¿Has implementado este patrón de desacoplamiento con colas en tus proyectos? Comparte tu experiencia y las variantes que hayas probado.
