Lambda es maravilloso, pero no es una bala de plata. Como toda herramienta, tiene límites técnicos y hay situaciones donde usarlo es una mala idea (antipatrones). Cerramos el capítulo aprendiendo a reconocer cuándo Lambda no es la respuesta correcta: saberlo te ahorrará disgustos y te hará un mejor arquitecto.

Lambda impone una serie de restricciones. No hace falta memorizar números exactos (cambian con el tiempo), pero sí conocer qué está limitado:

El límite más importante de recordar es el de los 15 minutos: una función Lambda no puede ejecutarse más de 15 minutos. Si tu tarea tarda más, Lambda no es la herramienta.

Un antipatrón es usar una herramienta para algo a lo que no está pensada. Estos son los casos donde Lambda no encaja:

Si un proceso tarda más de 15 minutos (procesar un vídeo enorme, un cálculo científico, una migración masiva de datos), Lambda lo cortará a la mitad.

Mejor alternativa: contenedores (ECS/Fargate, Capítulo 17), instancias EC2, o servicios de procesamiento por lotes. Para flujos largos formados por pasos cortos, se pueden orquestar varias Lambdas con Step Functions (Capítulo 28).

Lambda es genial para tráfico intermitente o impredecible (pagas solo por uso). Pero si tienes un tráfico enorme y constante las 24 horas, los miles de millones de ejecuciones pueden salir más caras que un grupo de servidores siempre encendidos.

Mejor alternativa: EC2 con Auto Scaling (Capítulo 13) o contenedores, que a volumen constante muy alto pueden ser más económicos. (Conviene hacer números: depende mucho del caso.)

Lambda es sin estado (stateless): cada invocación puede ejecutarse en un entorno distinto, y no puedes confiar en que la memoria se conserve entre llamadas. Si tu aplicación necesita mantener datos en memoria entre peticiones (una sesión de usuario en RAM, una caché local persistente), Lambda no es adecuado.

Mejor alternativa: guardar el estado fuera de la función, en servicios pensados para ello: DynamoDB (subcapítulo 8.3), ElastiCache (subcapítulo 8.4) o S3 (Capítulo 5). Esta es, de hecho, la forma correcta de diseñar: el estado va a un servicio externo, no en la función.

Como Lambda puede crear miles de ejecuciones en paralelo, cada una intentando abrir una conexión a una base de datos relacional (RDS, Capítulo 8), puede agotar las conexiones disponibles y tumbar la base de datos.

Mejor alternativa: usar RDS Proxy (que gestiona y reutiliza las conexiones), bases de datos serverless como Aurora Serverless (subcapítulo 8.2) o DynamoDB, que escalan mejor con Lambda.

Si necesitas latencia ultrabaja y garantizada en cada petición, y los cold starts (subcapítulo 14.4) son un problema constante incluso con provisioned concurrency, quizá un servicio siempre encendido sea mejor.

Lambda no sustituye a los servidores: es otra herramienta más en tu caja. Un buen arquitecto combina servicios: usa Lambda para el procesamiento de eventos y las tareas cortas, contenedores o EC2 para cargas constantes y largas, y servicios gestionados (DynamoDB, S3, colas) para el estado y los datos.

La pregunta clave no es «¿uso Lambda?», sino «¿qué herramienta encaja mejor con este trabajo concreto?». A veces es Lambda, a veces no, y muchas arquitecturas reales usan varias a la vez.

• Lambda tiene límites: el más importante es el de 15 minutos máximos de ejecución; también hay topes de memoria, tamaño de paquete, almacenamiento temporal y concurrencia.
• Antipatrones (cuándo NO usar Lambda): tareas de más de 15 min, tráfico constante altísimo 24/7, necesidad de estado en memoria entre peticiones, y mal manejo de conexiones a bases de datos relacionales a gran escala.
• El estado debe ir fuera de la función (DynamoDB, ElastiCache, S3): Lambda es sin estado.
• Alternativas según el caso: ECS/Fargate o EC2 (tareas largas/constantes), Step Functions (flujos largos por pasos), RDS Proxy / Aurora Serverless / DynamoDB (bases de datos a escala).
• La pregunta correcta es «¿qué herramienta encaja mejor con este trabajo?», no «¿uso Lambda para todo?».

¡Has terminado el Capítulo 14 y dominas los fundamentos de serverless! En el Capítulo 15 veremos las piezas que conectan todas estas funciones y servicios: la mensajería y los eventos (SQS, SNS, EventBridge), clave para construir sistemas desacoplados.