Do crescimento à eficiência: uma jornada com Aurora Serverless

No AWS Summit São Paulo, tive a oportunidade de compartilhar uma experiência prática ao lado de Murillo Da Costa Tavares e Luiz Fernando Moreira, da AWS. O tema da apresentação era Aurora e DynamoDB, mas a conversa que mais me interessa registrar aqui começa antes de qualquer serviço: como uma arquitetura responde quando o negócio cresce e as decisões que antes eram simples passam a se repetir em escala.

Este é o primeiro texto de uma série curta. Aqui, conto a parte que vai da arquitetura inicialmente concentrada à eficiência operacional com Aurora Serverless e automação interna. No próximo, explico como a mesma disciplina ajudou a preparar a continuidade entre Regiões: Resiliência entre Regiões: preparar antes do incidente.

Não é um tutorial de migração nem uma receita universal. É um relato sobre critérios, observação e construção de capacidade operacional. Em plataformas de dados, a tecnologia importa, mas a maneira de introduzi-la costuma definir se ela reduz complexidade ou apenas a desloca para outro lugar.

TL;DR

• A arquitetura concentrada era adequada quando a plataforma tinha outra escala; o crescimento pediu mais isolamento e autonomia por domínio.
• Separar schemas e bancos em clusters trouxe benefícios técnicos, mas multiplicou decisões de capacidade e tarefas operacionais.
• A adoção de Aurora Serverless foi gradual e observável: cada workload exigiu hipóteses de MIN e MAX, métricas e ajustes contínuos.
• A automação interna transformou conhecimento operacional em um caminho de autosserviço com aprovação, auditoria e reversão.

A arquitetura inicial não era um erro

É tentador narrar uma arquitetura anterior como se ela fosse um problema desde o primeiro dia. Não era o nosso caso. Uma plataforma mais concentrada pode ser a decisão certa quando o produto ainda está se formando, os domínios estão amadurecendo e a prioridade é entregar valor com uma operação compreensível.

Na experiência que apresentei, essa concentração cumpriu seu papel. Aplicações e schemas compartilhavam uma estrutura relacional que atendia bem ao momento da plataforma. O ponto de inflexão veio quando a variedade de domínios, clientes e ritmos de evolução aumentou. O que antes simplificava a gestão passou a aproximar demais componentes com necessidades distintas.

Essa mudança não se resolve apenas desenhando caixas novas em um diagrama. Ela pede uma pergunta mais concreta: quais decisões precisam ser independentes para que os times e os serviços possam evoluir sem carregar o mesmo risco operacional? Para nós, uma resposta importante foi tornar os limites de domínio também limites de dados.

Separar para ganhar autonomia e isolamento

Começamos a separar schemas e bancos em clusters alinhados aos domínios da plataforma. O ganho não era somente uma organização mais bonita. Reduzir acoplamento significava permitir que uma mudança ou uma necessidade de capacidade em um domínio não contaminasse automaticamente os demais.

Esse tipo de isolamento ajuda tanto na evolução técnica quanto na conversa entre times. Um domínio passa a ter fronteiras mais claras para observar uso, definir prioridades e entender o efeito das próprias decisões. A arquitetura deixa de depender apenas de coordenação informal para preservar estabilidade.

Mas toda autonomia tem custo. Passar de poucos clusters para uma frota maior amplia a superfície de operação: configurações, manutenção, acompanhamento de desempenho, dimensionamento, comunicação de mudanças e validação. A pergunta deixou de ser apenas “como isolamos melhor?” e passou a ser “como fazemos a operação continuar sustentável quando a repetição aumenta?”.

Foi um aprendizado importante para mim como engenheiro de plataforma de dados. Escalar não é multiplicar recursos e esperar que a mesma rotina funcione. É reconhecer cedo quais decisões precisam virar práticas repetíveis e quais ainda exigem julgamento específico.

Serverless como decisão de modelo operacional

Em ambientes provisionados, a capacidade costuma ser escolhida antes que a demanda aconteça. Essa margem é compreensível: ela protege desempenho e reduz incertezas diante de picos. Em uma frota grande, porém, a soma das margens pode significar recursos ociosos, custos descolados do comportamento real e uma fila recorrente de redimensionamentos.

Aurora Serverless entrou nesse contexto como uma forma de combinar elasticidade, custo total e segurança operacional. A palavra-chave aqui é combinação. Não buscamos “a instância mais barata”; buscamos uma operação que mantivesse desempenho, respondesse a variações de carga e diminuísse intervenções repetitivas sem tratar a migração como uma mudança abrupta e pouco controlada.

Por isso, a migração foi gradual e observável. Em vez de uma conversão em massa, cada componente pedia uma leitura do próprio perfil. Antes da mudança, estabelecíamos uma linha de base. Depois, acompanhávamos CPU, memória, latências, cache e o comportamento em períodos usuais e picos. A capacidade mínima e máxima não eram números mágicos: eram hipóteses que precisavam sobreviver ao uso real.

Essa distinção faz diferença. Um MIN muito baixo pode introduzir volatilidade onde a aplicação precisa de uma base estável de memória e cache. Um MAX mal escolhido pode limitar um pico legítimo ou pagar por uma margem sem necessidade. A prática foi usar a carga constante para orientar o piso e os picos para orientar o teto, revisando os limites à medida que o padrão de uso mudava.

O que vale levar para outros cenários não é uma promessa universal de resultado. É o método: medir, testar, ajustar e manter a decisão conectada ao comportamento da carga. Serverless fez sentido porque alterou o modelo operacional, aproximando capacidade e demanda sem dispensar observação e responsabilidade técnica.

Escalar a operação, não só o banco

Mesmo com elasticidade, há situações planejadas que o autoscaling não consegue adivinhar sozinho. Um evento conhecido, uma mudança coordenada ou uma janela de alta demanda pode pedir capacidade antes que a métrica reaja. Foi aí que ficou mais claro para mim que autoscaling e autosserviço resolvem problemas diferentes.

Autoscaling reage ao que está acontecendo. Autosserviço antecipa uma necessidade conhecida, mas sem devolver cada alteração ao mesmo fluxo manual de sempre. A intenção era criar autonomia para os times com os guardrails necessários à operação de dados: aprovação, rastreabilidade, prazo, auditoria e um caminho de reversão.

Na prática, isso virou um fluxo interno de solicitação, aprovação e execução orquestrada. Cada alteração preserva rastreabilidade, tem prazo definido e pode ser revertida automaticamente quando é temporária. O objetivo não era esconder o banco atrás de um botão; era transformar uma rotina repetitiva em um processo governado e verificável.

Essa camada muda a conversa sobre eficiência. Reduzir esforço operacional não é apenas gastar menos horas em uma tarefa. É liberar especialistas para trabalhar em observabilidade, exceções, análise de risco e decisões que não podem ser padronizadas. A automação não substitui o julgamento técnico; ela protege esse julgamento de ser consumido por repetição.

O valor de negócio aparece na soma das fases

Separação por domínio, Aurora Serverless e automação interna parecem decisões distintas quando observadas isoladamente. Na prática, elas formam uma sequência. O isolamento melhora autonomia. A elasticidade aproxima capacidade e demanda. A automação transforma conhecimento em um processo reproduzível. Juntas, essas fases ajudam a reduzir acoplamento, alinhar custos ao uso e tornar a operação mais previsível.

Foi isso que procurei mostrar no Summit: arquitetura de dados não é uma entrega pontual. É uma jornada de escolhas que precisam continuar fazendo sentido quando o negócio, a frota e as responsabilidades dos times mudam. Minha contribuição nessa trajetória foi atuar no encontro entre banco de dados, desempenho, observabilidade e operação, buscando decisões que fossem tecnicamente sólidas e compreensíveis para quem precisaria operá-las depois.

A próxima etapa da série leva essa mesma mentalidade para a continuidade entre Regiões. O desafio deixa de ser apenas operar melhor em condições normais e passa a ser preparar dados, aplicação e decisões para que uma indisponibilidade não comece com reconstrução: Resiliência entre Regiões: preparar antes do incidente.