Lambda como backend total y central

Hace unas semanas vi un post de si podía meter toda una API en una sola función Lambda. Le miré raro, como cuando alguien te pregunta si puede meter el sofá, la nevera y la cama en la misma habitación. Técnicamente sí me di cuenta de que no hay casi nada escrito en español sobre esto. Así que aquí va.

Lo que en inglés llaman "Lambdalith" yo prefiero llamarlo Lambda como backend total: una sola función Lambda que atiende todas las rutas de tu API, en vez de una función por endpoint. Todo el tráfico entra por el mismo sitio y dentro decides a dónde va, normalmente con el framework que ya conoces (FastAPI, Express, Next.js, Flask...) montado encima con algo como el Lambda Web Adapter, o ni si quiera.

1. Esto no va de monolito contra microservicios

Antes de nada, una aclaración que mucha gente mezcla. Lambda como backend total no es lo mismo que monolito vs. microservicios. Puedes tener un "Lambda como backend total" que sea un microservicio dentro de un sistema más grande, o puedes tener uno que sea literalmente todo tu backend. Son dos preguntas distintas: cómo divides tu sistema, y cuántas funciones usas para servir una API.

No las confundas, porque si las mezclas acabas discutiendo de arquitectura sin saber ni de qué hablas.

2. Cómo se monta en la práctica

El truco que lo hace posible es el Lambda Web Adapter. Coges tu API hecha con Express, FastAPI, Next.js o Flask, tal cual la escribirías para un servidor normal, y el adapter traduce los eventos de Lambda a peticiones HTTP que tu framework entiende.

Si quieres puedes empaquetarlo como imagen de contenedor o como zip. Para un equipo que viene de toda la vida montando servidores, esto es oro: no reescribes nada, solo cambias dónde vive el código.

Pero igualmente no todo son maravillas, porque no puedes montar un servidor MCP, tampoco puedes hacer tareas que requieran más de 15 minutos, y con memoria puedes ir algo limitado, es algo que de entrada ya conocemos pero realmente allí es cuando te das cuenta de si necesitas una lambda o no, las lambdas están bien pero para cosas grandes vas a tener que ir siempre a un contenedor, ten en cuenta eso, porque si no te vas a ahorrar tiempo saltando al contenedor directamente, los contenedores también tienen su magia y me encantan.

3. Los contras

Cold starts más largos. Cuantas más rutas metes en la misma función, más dependencias arrastra, y más pesa el paquete. La regla que manejan por ahí es que cada 10 MB de más en el código sin comprimir te cuesta unos 100 ms de cold start. Next.js sin comprimir pesa 111 MB. Haz la cuenta. Y el propio Lambda Web Adapter añade su granito de arena, unos cuantos milisegundos extra por si acaso.

Realmente el cold start no te va a importar mucho si no necesitas inmediatez, pero siempre está bien tenerlo en cuenta, va a depender de tu caso de uso.

Mezclar cosas que no deberían ir juntas. Si tu función hace tanto server-side rendering como endpoints de API pura, las dos partes se penalizan entre sí sin necesidad. La parte de API paga el peso de la parte de rendering, y viceversa.

Pierdes visibilidad fina. Con una función por endpoint, API Gateway y Lambda te dan métricas por ruta de fábrica, sin hacer nada. Con todo metido en una función, esa granularidad desaparece. Si algo va lento, ya no sabes de un vistazo si es el endpoint de login o el de subir facturas: es "la función", a secas. Tienes que montarte tú la instrumentación, con Embedded Metric Format o con algo como Lumigo, para recuperar esa información.

Escalado más lento en picos bruscos. Lambda te da 1.000 ejecuciones concurrentes desde ya y suma otras 1.000 cada 10 segundos. Con una sola función absorbiendo todo el tráfico, ese límite lo comparte toda tu API. Con varias funciones, cada una escala por su lado, así que el conjunto responde más rápido cuando te llega un pico. Si tu producto puede tener subidas bruscas de tráfico, esto pesa.

4. Los pros

Cold starts más bajos en APIs con poco tráfico. Suena contradictorio con el punto anterior, pero tiene sentido: si concentras todo el tráfico en una función, esa función se mantiene "caliente" con más frecuencia. Con muchas funciones pequeñas y poco tráfico cada una, cada endpoint se enfría por su cuenta y sufres cold starts por todas partes.

Migración e integración con contenedores mucho más simple. Si mañana decides que quieres mover esto a ECS o a Kubernetes, tu código ya está escrito como una app normal. No tienes que deshacer nada. Esta probablemente sea la mejor parte porque si decides hacer un lambdalith y tienes tu venv en Python y es cuestión de migrarlo solamente tendrás que cambiar la infraestructura porque el resto ya lo tienes todo.

La curva de aprendizaje es la que ya tenías. Un equipo que viene de desarrollar apps web tradicionales no tiene que reaprender a pensar en "una función por ruta". Sigue organizando el código como siempre lo ha hecho, con sus tests de toda la vida, su estructura de carpetas de toda la vida.

Ahorro de costes usando Function URLs en vez de API Gateway. Te quitas de encima el coste de API Gateway y usas las Function URLs de Lambda directamente. No es una fortuna, pero suma.

Streaming de respuesta y payloads grandes. Puedes hacer streaming de la respuesta y superar el límite de 10 MB que impone API Gateway. Si tu API mueve archivos grandes o necesitas ir devolviendo la respuesta poco a poco, esto es un punto a favor nada despreciable.

Sobre todo diría que para desarrollar es más cómodo, he visto en empresas españolas cómo se empiezan a liar con microservicios cuando realmente lo que tienen que aprender es a colaborar mejor, a aprender a colaborar y ya, pero cada quien toma sus decisiones que crean una deuda técnica o no, realmente ahora con la llegada de los LLMs realmente es importante saber qué infraestructura hacer y no tanto pensar en el código porque el código se hará solo.

5. Entonces, ¿cuándo tiene sentido?

Usa Lambda como backend total cuando...

• Vienes de una app web tradicional y quieres migrar a serverless sin reescribir medio producto.
• Tienes un CRUD, algunas llamadas a otras APIs, realmente no te excedes en librerías, y sobretodo tiene sentido que este todo junto.
• Tu tráfico es bajo o irregular, y te preocupa más el cold start medio que el pico extremo
• Tu equipo no tiene tiempo (ni ganas) de reaprender a pensar en funciones por endpoint
• No te quieres complicar porque al hacer microservicios vas a tener que hacer contratos unos con otros que cambiarlos te va a generar dolor
• Necesitas streaming o payloads que no caben en el límite de API Gateway

Piénsatelo dos veces cuando...

• Necesitas escalar muy rápido ante picos bruscos de tráfico
• La observabilidad por endpoint es crítica para ti (por ejemplo, en un sistema con SLAs estrictos)
• Necesitas procesos largos, análisis complejo, o si simplemente estás en algún entorno que no te deje hacer streaming y necesites streaming.
• Tu API ya arrastra muchas dependencias pesadas y el cold start se te está yendo de las manos

Para cerrar

Lambda como backend total no es una chapuza ni una solución de segunda. Es un intercambio, como casi todo en arquitectura: cambias observabilidad de fábrica y escalado agresivo por velocidad de desarrollo y una migración sin dolor. Para un equipo que quiere probar serverless sin quemar tres meses reescribiendo todo, es probablemente la mejor puerta de entrada que existe hoy.

Lo que no puedes hacer es elegirlo porque "es lo que hace todo el mundo" o porque suena más simple sobre el papel. Elígelo porque conoces el trade-off y lo has decidido tú, no porque te lo haya dicho un hilo de Twitter. La arquitectura, al final, no va de tener razón. Va de saber qué estás sacrificando y estar dispuesto a pagarlo.