Cuando trabajamos con arquitecturas serverless, uno de los conceptos más poderosos y a la vez más malinterpretados es el asincronismo. Lejos de significar lentitud, representa optimización, delegación y buenas prácticas que permiten construir aplicaciones escalables y resilientes. Comprender cómo Lambda gestiona la concurrencia y cuándo conviene procesar eventos de forma asíncrona marca la diferencia entre una plataforma robusta y una que colapsa bajo presión.
¿Por qué el asincronismo no significa lentitud?
Una preocupación frecuente es pensar que hacer algo asíncrono hará la aplicación más lenta. Sin embargo, asincronismo es sinónimo de optimización y delegación [0:30]. A nivel de usuario, normalmente no se percibe si un proceso es síncrono o asíncrono. De hecho, muchas aplicaciones de pagos procesan sus transacciones de forma asíncrona, y las redes sociales, al manejar grandes volúmenes de tráfico, delegan múltiples procesos para que se ejecuten en segundo plano [0:55].
Un caso habitual a nivel de desarrollo ocurre cuando múltiples Lambdas intentan acceder a una base de datos para modificar un mismo registro. Esto puede generar implicaciones en la base de datos y, dependiendo de la regla de negocio, convertirse en un proceso asíncrono que reduzca bloqueos [1:10].
La regla de oro es clara: todo lo que pueda ser asíncrono, que sea asíncrono [3:45]. Sin embargo, determinar qué procesos califican depende de la experiencia y del entendimiento del negocio.
¿Qué diferencia hay entre reserved concurrency y provisioned concurrency?
AWS Lambda ofrece dos mecanismos de configuración de concurrencia que suelen confundirse, pero cumplen funciones distintas [2:05].
¿Cómo funciona el reserved concurrency?
El reserved concurrency es un número que le indica a Lambda cuántas instancias pueden ejecutarse en paralelo [2:20]. Por ejemplo, si configuramos la función de thumbnail (redimensionamiento de imágenes) con un reserved concurrency de tres, solo tres imágenes podrán procesarse simultáneamente. Sin esta configuración, una llegada masiva de imágenes al bucket podría saturar Lambda y alcanzar los soft limits, que por defecto son mil ejecuciones concurrentes [2:40].
¿Qué papel juega el provisioned concurrency?
El provisioned concurrency funciona como el equipo de reserva en un partido de fútbol [3:05]. Son instancias de Lambda que están precalentadas y listas para atender peticiones cuando las instancias activas se saturen o se genere un cuello de botella. Mientras el reserved concurrency define las Lambdas ejecutándose, el provisioned concurrency garantiza que haya Lambdas preparadas para responder de inmediato [3:20].
Esta capacidad se alinea con las buenas prácticas del AWS Well-Architected Framework y el modelo de responsabilidad compartida, donde AWS gestiona gran parte del trabajo pesado [3:35].
¿Cómo se integra SQS para procesar likes de forma asíncrona?
Un ejemplo práctico es el sistema de likes en redes sociales [4:35]. Cuando un post se vuelve viral y miles de personas dan like al mismo tiempo, para el usuario parece un proceso instantáneo. Sin embargo, internamente esos likes se envían a un servicio de colas como SQS (Simple Queue Service). Posteriormente, un worker o backend toma esos documentos encolados y los suma a la base de datos [4:55].
- Cuando das un corazón en Instagram, ese dato no cae directamente en la base de datos.
- En realidad queda encolado para procesarse después.
- Esto evita saturar la base de datos con escrituras concurrentes.
¿Qué otros servicios generan eventos asíncronos?
Además de S3 y SQS, existen otros servicios que disparan eventos asíncronos [5:25]:
- CloudWatch: monitoreo y alarmas.
- EventBridge: orquestación de eventos entre servicios.
- DynamoDB Streams: cambios en tablas NoSQL.
- RDS y RDS Proxy: conexión optimizada a bases de datos relacionales.
- Auto Scaling Group: ajuste automático de capacidad.
El RDS Proxy merece mención especial [4:10]. Amazon lo creó para resolver una falencia conocida: las bases de datos relacionales fueron diseñadas antes del paradigma serverless y presentan problemas con muchas conexiones concurrentes. Este servicio actúa como intermediario, permitiendo que múltiples Lambdas se conecten sin saturar la base de datos.
Finalmente, es fundamental que frontend y backend sean compatibles con el modelo asíncrono [5:45]. Diseñar un backend que siempre espere respuestas síncronas cuando la infraestructura opera de forma asíncrona genera cuellos de botella y puede comprometer la estabilidad de toda la plataforma. ¿Ya has identificado procesos en tus proyectos que podrían volverse asíncronos? Comparte tu experiencia.
