A Escala Que Você Não Vê em Demos
Quando você constrói um sistema serverless pela primeira vez, pensa em números pequenos. Algumas funções Lambda, talvez algumas dezenas no máximo. Mas o que acontece quando sua plataforma opera milhares de contas AWS e implanta mais de um milhão de funções Lambda em produção, cada uma isolada para um único cliente?
A ProGlove, empresa por trás das soluções inteligentes de leitura de código de barras vestíveis, enfrentou exatamente esse desafio. A plataforma SaaS deles, Insight, começou com o manual serverless padrão—SQS para desacoplamento, EventBridge para eventos, DynamoDB para armazenamento. Mas, à medida que cresceram de 1 para mais de 1.000 contas, descobriram que muitas "melhores práticas" quebram em escala.
Esta é a história deles, destilada em lições que você pode aplicar antes de sentir a dor.
Fase 1: As Origens Simples (0 → 1.000 Funções)
No começo, tudo funcionava perfeitamente. Cada microsserviço seguia uma estrutura consistente: 5 a 15 funções Lambda coordenadas por Step Functions, com EventBridge roteando eventos e DynamoDB como armazenamento principal. O AWS CloudFormation StackSets parecia um superpoder—uma operação de implantação atualiza muitas contas simultaneamente.
Mas a primeira armadilha estava escondida: custos ociosos. Mesmo com serverless, "ocioso" não significa custo zero. Funções Lambda consumindo eventos do EventBridge através de uma fila SQS fazem polling constante da fila, mesmo quando não há mensagens. Em escala pequena, isso é desprezível. Em 1.000 contas, vira uma linha de custo que você não pode ignorar.
Insight chave: Scale-to-zero não é apenas um bom ter. É uma necessidade financeira.
Fase 2: As Primeiras 50 Contas – Problemas Reais Aparecem
Crescer para 50 contas de inquilinos forçou três decisões arquiteturais deliberadas:
1. Fábrica de Contas Automatizada
Provisionamento manual não escala. A ProGlove construiu uma fábrica de contas automatizada em cima do AWS Organizations: um workflow Step Functions na conta de gerenciamento lida com todo o ciclo de vida—criar a conta, aplicar SCPs, bootstrapping de roles IAM e disparar implantações iniciais do StackSet. Novas contas de inquilinos vão de solicitação a prontas em menos de 15 minutos, com custo incremental próximo de zero.
2. O Superpoder do Isolamento de Cotas
Uma vantagem subestimada do modelo conta-por-inquilino é a separação de cotas. Cada conta tem seu próprio limite de execução concorrente Lambda, throttle do API Gateway e cotas de serviço. Em um modelo de conta compartilhada, um único inquilino barulhento poderia exaurir a concorrência compartilhada e causar falhas em cascata. Com isolamento de conta, esse tipo de problema simplesmente não existe.
3. Custos de Observabilidade Batem Forte
A $3 por conta por mês para encaminhar logs do CloudWatch para uma plataforma de observabilidade terceirizada, o custo parecia insignificante. Mas em milhares de contas, esses $3/conta/mês se tornam uma despesa impactante. A ProGlove aprendeu a tratar custos de observabilidade por conta com o mesmo escrutínio que custos de computação. Diferenciando dados de alta e baixa prioridade, eles reduziram os custos de observabilidade para ~$0,70 por conta, e quase zero para contas inativas.
Fase 3: O Problema do Auto-DDoS
Quando centenas de instâncias de serviços de backend acessam simultaneamente outros serviços, o volume de requisições resultante pode se assemelhar a um ataque coordenado. A ProGlove experimentou isso em primeira mão: um pico massivo de métricas onde suas próprias funções sobrecarregaram APIs internas.
Causa raiz: Agendamentos sincronizados. Cada Lambda usava a mesma expressão de taxa de 5 minutos, alinhada ao topo do minuto em milhares de contas.
Solução: Dispersão de requisições—uma biblioteca interna padronizada que impõe jitter, offsets de lote aleatórios e atualizações escalonadas em todas as funções agendadas.
Regra de Ouro: Nunca faça a mesma coisa ao mesmo tempo em todos os lugares.
Fase 4: Repensando Padrões Arquiteturais para Scale-to-Zero
A lição mais dolorosa: as "melhores práticas" tradicionais do SQS aumentaram os custos em escala. A correção foi radical:
- Remover o SQS do caminho EventBridge → Lambda. Em vez de fazer polling das filas, use segurança baseada em métricas—monitore
AsyncEventsDroppedeConcurrentExecutionspara ficar dentro das cotas sem perder eventos. - Centralizar a DLQ. Fazer polling de Dead Letter Queues individuais em cada conta reintroduziu os mesmos problemas de custo. Roteando falhas para uma única DLQ centralizada eliminou os custos de polling, embora tenha exigido disciplina extrema para manter o isolamento de dados (usando o ID da conta AWS como ID do inquilino).
Fase 5: Industrializando o Motor de Implantação
Em 1 milhão de funções Lambda, o CloudFormation StackSets atingiu um teto de desempenho. A ProGlove começou a construir seu próprio sistema de implantação interno—até que a equipe de serviço do AWS CloudFormation interveio. Engajando cedo e frequentemente, eles influenciaram o roadmap e priorizaram melhorias de estabilidade no StackSet.
Eles também construíram um serviço de rastreamento de implantação que agrega eventos do StackSet através do EventBridge, com uma máquina de estados Step Functions central atuando como um "painel único" para falhas e novas tentativas.
Fase 6: Governança Madura e FinOps
A Estratégia Mono-Repo
A ProGlove consolidou 20 microsserviços em um único mono-repo. Isso permitiu:
- Ferramentas consistentes e varredura de segurança em mais de 1 milhão de funções
- Atualizações coordenadas de runtime e bibliotecas através de uma única fonte de verdade
- Compatibilidade garantida através do pipeline CI/CD
A Realidade do "Quase Zero"
Mesmo com um mandato de scale-to-zero, "zero" é frequentemente "quase zero." Monitoramento introduz custos—CloudWatch Alarms, ferramentas de observabilidade externas. Mas otimizando agressivamente, eles reduziram o custo ocioso para contas inativas a menos de $1 por mês.
Pense Além dos Serviços Óbvios
Antes de escrever uma função Lambda, pergunte se uma integração nativa de serviço AWS já resolve o problema. Serviços como EventBridge Pipes, AppSync e SQS FIFO podem remover categorias inteiras de código personalizado. O Serverless Land é um excelente ponto de partida para descobrir padrões que você pode não ter considerado.
Limitações e Cuidados
- Modelo conta-por-inquilino não é adequado para todos os cenários. Aumenta a sobrecarga de gerenciamento e requer automação robusta. Se seu número de inquilinos for inferior a 20, a complexidade pode não valer a pena.
- DLQ centralizada introduz uma potencial violação de isolamento de dados. Você deve tratar IDs de conta AWS como IDs de inquilino e aplicar controles de acesso rigorosos.
- Custos de observabilidade terceirizada podem disparar. Sempre negocie preços por conta ou considere alternativas auto-hospedadas para cenários de alto volume.
Próximos Passos para Seu Aprendizado
- Audite sua arquitetura serverless atual em busca de custos de polling ocioso. Você pode remover o SQS dos caminhos EventBridge → Lambda?
- Implemente jitter e dispersão de requisições em qualquer função Lambda agendada.
- Explore integrações nativas da AWS antes de escrever código personalizado. Confira o Serverless Land para padrões.
- Considere um mono-repo se você gerencia múltiplos microsserviços—consistência em escala é um multiplicador de força.
Para uma visão mais profunda de como as plataformas de dados estão evoluindo junto com serverless, veja nosso artigo sobre Visão de Banco de Dados da Microsoft para 2026. E se você está curioso sobre como sistemas de recomendação baseados em IA lidam com intenção em escala, leia Como a Airbnb Construiu um Modelo de Recomendação de Destino.
Este artigo é baseado no post original do AWS Architecture Blog.
