La Escala Que No Ves en Demos
Cuando construyes un sistema serverless por primera vez, piensas en números pequeños. Un puñado de funciones Lambda, tal vez unas docenas como máximo. Pero ¿qué pasa cuando tu plataforma opera miles de cuentas AWS y despliega más de un millón de funciones Lambda en producción, cada una aislada para un solo cliente?
ProGlove, la empresa detrás de las soluciones inteligentes de lectura de códigos de barras portátiles, enfrentó exactamente este desafío. Su plataforma SaaS, Insight, comenzó con el manual serverless estándar—SQS para desacoplamiento, EventBridge para eventos, DynamoDB para almacenamiento. Pero a medida que crecieron de 1 a más de 1,000 cuentas, descubrieron que muchas "mejores prácticas" se rompen a escala.
Esta es su historia, destilada en lecciones que puedes aplicar antes de sentir el dolor.
Fase 1: Los Orígenes Simples (0 → 1,000 Funciones)
Al principio, todo funcionaba perfectamente. Cada microservicio seguía una estructura consistente: 5 a 15 funciones Lambda coordinadas por Step Functions, con EventBridge enrutando eventos y DynamoDB como almacenamiento principal. AWS CloudFormation StackSets se sentía como un superpoder—una operación de despliegue actualiza muchas cuentas simultáneamente.
Pero la primera trampa estaba oculta: costos inactivos. Incluso con serverless, "inactivo" no significa costo cero. Las funciones Lambda que consumen eventos de EventBridge a través de una cola SQS hacen polling constante de la cola, incluso cuando no hay mensajes. A pequeña escala, esto es insignificante. En 1,000 cuentas, se convierte en una línea de costo que no puedes ignorar.
Insight clave: Scale-to-zero no es solo un buen tener. Es una necesidad financiera.
Fase 2: Las Primeras 50 Cuentas – Problemas Reales Aparecen
Crecer a 50 cuentas de inquilinos forzó tres decisiones arquitectónicas deliberadas:
1. Fábrica de Cuentas Automatizada
El aprovisionamiento manual no escala. ProGlove construyó una fábrica de cuentas automatizada sobre AWS Organizations: un workflow de Step Functions en la cuenta de gestión maneja todo el ciclo de vida—crear la cuenta, aplicar SCPs, bootstrapping de roles IAM y disparar despliegues iniciales de StackSet. Las nuevas cuentas de inquilinos pasan de solicitud a listas en menos de 15 minutos, con costo incremental casi nulo.
2. El Superpoder del Aislamiento de Cuotas
Una ventaja subestimada del modelo cuenta-por-inquilino es la separación de cuotas. Cada cuenta tiene su propio límite de ejecución concurrente Lambda, throttle de API Gateway y cuotas de servicio. En un modelo de cuenta compartida, un solo inquilino ruidoso podría agotar la concurrencia compartida y causar fallos en cascada. Con aislamiento de cuenta, ese tipo de problema simplemente no existe.
3. Costos de Observabilidad Golpean Fuerte
A $3 por cuenta por mes para reenviar logs de CloudWatch a una plataforma de observabilidad de terceros, el costo parecía insignificante. Pero en miles de cuentas, esos $3/cuenta/mes se convierten en un gasto impactante. ProGlove aprendió a tratar los costos de observabilidad por cuenta con el mismo escrutinio que los costos de cómputo. Diferenciando datos de alta y baja prioridad, redujeron los costos de observabilidad a ~$0.70 por cuenta, y casi cero para cuentas inactivas.
Fase 3: El Problema del Auto-DDoS
Cuando cientos de instancias de servicios backend acceden simultáneamente a otros servicios, el volumen de solicitudes resultante puede parecerse a un ataque coordinado. ProGlove lo experimentó de primera mano: un pico masivo de métricas donde sus propias funciones abrumaron las APIs internas.
Causa raíz: Programaciones sincronizadas. Cada Lambda usaba la misma expresión de tasa de 5 minutos, alineada al inicio del minuto en miles de cuentas.
Solución: Dispersión de solicitudes—una biblioteca interna estandarizada que impone jitter, offsets de lote aleatorios y actualizaciones escalonadas en todas las funciones programadas.
Regla de Oro: Nunca hagas lo mismo al mismo tiempo en todas partes.
Fase 4: Repensando Patrones Arquitectónicos para Scale-to-Zero
La lección más dolorosa: las "mejores prácticas" tradicionales de SQS aumentaron los costos a escala. La corrección fue radical:
- Eliminar SQS del camino EventBridge → Lambda. En lugar de hacer polling de las colas, usa seguridad basada en métricas—monitorea
AsyncEventsDroppedyConcurrentExecutionspara mantenerte dentro de las cuotas sin perder eventos. - Centralizar la DLQ. Hacer polling de Dead Letter Queues individuales en cada cuenta reintrodujo los mismos problemas de costo. Enrutando fallos a una única DLQ centralizada eliminó los costos de polling, aunque requirió disciplina extrema para mantener el aislamiento de datos (usando el ID de cuenta AWS como ID de inquilino).
Fase 5: Industrializando el Motor de Despliegue
En 1 millón de funciones Lambda, CloudFormation StackSets alcanzó un techo de rendimiento. ProGlove comenzó a construir su propio sistema de despliegue interno—hasta que el equipo de servicio de AWS CloudFormation intervino. Al comprometerse temprano y con frecuencia, influyeron en el roadmap y priorizaron mejoras de estabilidad en StackSet.
También construyeron un servicio de seguimiento de despliegues que agrega eventos de StackSet a través de EventBridge, con una máquina de estados Step Functions central actuando como un "panel único" para fallos y reintentos.
Fase 6: Gobernanza Madura y FinOps
La Estrategia Mono-Repo
ProGlove consolidó 20 microservicios en un solo mono-repo. Esto permitió:
- Herramientas consistentes y escaneo de seguridad en más de 1 millón de funciones
- Actualizaciones coordinadas de runtime y librerías a través de una única fuente de verdad
- Compatibilidad garantizada a través del pipeline CI/CD
La Realidad del "Casi Cero"
Incluso con un mandato de scale-to-zero, "cero" es a menudo "casi cero." El monitoreo introduce costos—CloudWatch Alarms, herramientas de observabilidad externas. Pero optimizando agresivamente, redujeron el costo inactivo para cuentas inactivas a menos de $1 por mes.
Piensa Más Allá de los Servicios Obvios
Antes de escribir una función Lambda, pregúntate si una integración nativa de servicio AWS ya resuelve el problema. Servicios como EventBridge Pipes, AppSync y SQS FIFO pueden eliminar categorías enteras de código personalizado. Serverless Land es un excelente punto de partida para descubrir patrones que quizás no hayas considerado.
Limitaciones y Precauciones
- Modelo cuenta-por-inquilino no es adecuado para todos los escenarios. Aumenta la sobrecarga de gestión y requiere automatización robusta. Si tu número de inquilinos es inferior a 20, la complejidad puede no valer la pena.
- DLQ centralizada introduce una potencial violación de aislamiento de datos. Debes tratar los IDs de cuenta AWS como IDs de inquilino y aplicar controles de acceso estrictos.
- Costos de observabilidad de terceros pueden dispararse. Siempre negocia precios por cuenta o considera alternativas auto-alojadas para escenarios de alto volumen.
Próximos Pasos para Tu Aprendizaje
- Audita tu arquitectura serverless actual en busca de costos de polling ocioso. ¿Puedes eliminar SQS de los caminos EventBridge → Lambda?
- Implementa jitter y dispersión de solicitudes en cualquier función Lambda programada.
- Explora integraciones nativas de AWS antes de escribir código personalizado. Revisa Serverless Land para patrones.
- Considera un mono-repo si gestionas múltiples microservicios—la consistencia a escala es un multiplicador de fuerza.
Para una mirada más profunda a cómo las plataformas de datos están evolucionando junto con serverless, consulta nuestro artículo sobre Visión de Base de Datos de Microsoft para 2026. Y si tienes curiosidad sobre cómo los sistemas de recomendación basados en IA manejan la intención a escala, lee Cómo Airbnb Construyó un Modelo de Recomendación de Destino.
Este artículo se basa en el post original del AWS Architecture Blog.
