Empresas SaaS costumam celebrar apenas os casos de sucesso. Porém, na prática, os maiores aprendizados normalmente surgem durante os erros mais caros.
Neste episódio do Guru Talks, André Cruz, CEO e cofundador da Digital Manager Guru, compartilhou um caso real envolvendo uma migração de dados que gerou uma cobrança inesperada de US$ 18.500 em apenas dois dias.
Apesar do prejuízo inicial, a experiência resultou numa redução permanente de aproximadamente 92% nos custos de armazenamento, gerando uma economia anual estimada entre US$ 60 mil e US$ 80 mil.
Mais do que um relato sobre infraestrutura, esta história mostrou como decisões de arquitetura, inteligência artificial e experiência prática precisam caminhar juntas para escalar uma operação SaaS com segurança.
- 1. O problema de acreditar que projetos de tecnologia são perfeitos
- 2. O desafio de migrar quase 900 milhões de registros
- 3. Por que o Firestore deixou de fazer sentido
- 4. A escolha pelo BigQuery
- 5. Como a Inteligência Artificial acelerou toda a migração
- 6. A importância de validar tudo que a IA produz
- 7. Quando surgiu a conta de US$ 18.500
- 8. O erro de arquitetura que ninguém previu
- 9. Como a solução foi redesenhada
- 10. As principais lições para empresas SaaS
O mito dos projetos perfeitos na tecnologia
[00:19] Segundo André Cruz, existe uma percepção muito comum na internet de que projetos de tecnologia acontecem rapidamente, sem dificuldades e praticamente sem custos.
Na realidade, empresas SaaS convivem diariamente com desafios técnicos, limitações de infraestrutura e decisões complexas que raramente aparecem nos conteúdos publicados por influenciadores.
Foi exatamente esse tipo de realidade que motivou o compartilhamento deste caso.
O objetivo não era mostrar um projeto perfeito, mas sim apresentar como problemas reais podem gerar aprendizados extremamente valiosos.
Um erro caro que mudou toda a arquitetura da plataforma
[00:47] A Digital Manager Guru precisava resolver um problema que crescia há vários anos.
A plataforma armazenava um enorme histórico de auditoria responsável por registrar praticamente todas as operações realizadas pelos clientes.
Esses registros incluem informações como:
- alterações realizadas pelos utilizadores;
- payloads recebidos dos processadores de pagamento;
- respostas enviadas para webhooks;
- logs internos da plataforma;
- histórico completo de operações críticas.
Ao longo dos anos, esse volume tornou-se gigantesco.
A empresa já armazenava aproximadamente 900 milhões de linhas de auditoria, com crescimento diário superior a 500 mil novos registos.
Esse crescimento tornava inevitável uma revisão completa da estratégia de armazenamento.
O problema do Firestore
[05:37] Quando o sistema foi desenvolvido, o Firestore era uma excelente escolha.
Ele oferecia:
- baixa latência;
- elevada velocidade de leitura;
- escrita extremamente rápida;
- ótimo desempenho para dados operacionais.
Entretanto, o cenário mudou completamente conforme a plataforma cresceu.
Grande parte dos dados armazenados passou a ser utilizada apenas para auditoria e consultas ocasionais.
Ou seja, tratava-se de dados frios, cujo custo de armazenamento passou a representar uma parcela significativa da infraestrutura.
Segundo André Cruz, a empresa estava literalmente pagando milhares de dólares por mês apenas para manter informações que raramente eram consultadas.
A decisão de migrar para o BigQuery
[7:33] A alternativa encontrada foi utilizar o Google BigQuery, solução desenhada especificamente para trabalhar com grandes volumes de dados analíticos.
Entre as vantagens estavam:
- custo muito inferior de armazenamento;
- elevada capacidade para trabalhar com bilhões de registos;
- excelente desempenho em consultas analíticas;
- escalabilidade praticamente ilimitada.
Na teoria, parecia a solução perfeita.
O objetivo era reduzir drasticamente os custos de infraestrutura sem perder a capacidade de auditoria da plataforma.
O primeiro obstáculo inesperado
[8:28] Durante a exportação dos dados surgiu um problema que ninguém havia previsto.
Parte das informações migradas para o BigQuery passou a aparecer em formato binário, tornando diversos campos ilegíveis.
Esses dados eram essenciais para consultas futuras.
Refazer toda a migração utilizando pipelines tradicionais significaria semanas de desenvolvimento, elevado custo operacional e muito risco.
Foi nesse momento que a Inteligência Artificial passou a desempenhar um papel decisivo.
Como a Inteligência Artificial acelerou toda a migração
[9:28] Segundo André Cruz, a IA foi utilizada como um verdadeiro parceiro técnico.
Em conjunto com ela, foi desenvolvido um pequeno decodificador em JavaScript, executado diretamente dentro do BigQuery através de uma User Defined Function (UDF).
Essa abordagem permitiu interpretar corretamente os dados binários durante o próprio processo de leitura.
O resultado impressionou.
Quase 900 milhões de registros foram convertidos corretamente por apenas algumas dezenas de euros em custo computacional.
Até esse momento, tudo indicava que a migração havia sido um enorme sucesso.
A validação evitou um problema ainda maior
[10:56] Mesmo com os excelentes resultados obtidos pela IA, André Cruz decidiu validar toda a conversão utilizando uma implementação independente.
Essa decisão revelou um erro crítico.
Alguns valores monetários negativos estavam sendo interpretados incorretamente, gerando números completamente absurdos.
Caso a equipa tivesse confiado cegamente na Inteligência Artificial, milhões de registros históricos poderiam ter sido corrompidos.
Esse episódio reforçou uma das mensagens centrais do vídeo:
A IA acelera a execução, mas nunca substitui processos sólidos de validação.
Em vez de confiar automaticamente no resultado produzido pela ferramenta, a Digital Manager Guru utilizou validações paralelas para garantir a integridade de toda a migração.
Essa prática evitou um problema potencialmente muito mais grave do que o custo financeiro que surgiria posteriormente.
Quando surgiu a conta de US$ 18.500
[12:51] Depois de um sábado inteiro dedicado à migração, tudo parecia ter corrido conforme o esperado.
Os testes haviam sido concluídos com sucesso, os dados estavam disponíveis no novo ambiente e os custos da própria migração tinham sido extremamente baixos.
No domingo à noite, antes de encerrar o fim de semana, André Cruz decidiu apenas verificar o painel financeiro da Google Cloud por precaução.
Foi nesse momento que surgiu a surpresa.
O relatório apresentava uma cobrança acumulada de aproximadamente US$ 18.500 em apenas dois dias.
Embora a migração tivesse sido concluída corretamente, havia um problema completamente diferente que ainda não tinha sido identificado.
O verdadeiro problema não era armazenar os dados
[14:46] A migração em si não tinha falhado.
O problema estava na forma como os dados eram consultados depois de estarem armazenados no BigQuery.
Foi exatamente aqui que surgiu um dos maiores aprendizados de arquitetura de software apresentados durante o Guru Talks.
Enquanto o Firestore cobra principalmente pelas operações de leitura e escrita utilizando índices extremamente eficientes, o BigQuery trabalha com um modelo completamente diferente.
O custo está diretamente relacionado com o volume de dados analisados em cada consulta.
Na prática, isso significa que uma consulta aparentemente simples pode obrigar o BigQuery a percorrer terabytes de informação.
Foi precisamente isso que aconteceu.
O erro de arquitetura que gerou milhares de dólares em custos
[16:13] Durante a migração, toda a informação da auditoria foi armazenada dentro de grandes estruturas JSON.
Sempre que um utilizador consultava uma auditoria através do painel administrativo, da API ou de qualquer interface da plataforma, o BigQuery precisava analisar enormes quantidades de dados para localizar poucos registos.
O resultado foi surpreendente.
Uma única consulta passou a analisar aproximadamente 2 terabytes de informação.
Em produção, centenas de consultas semelhantes eram executadas continuamente.
Em pouco tempo, o consumo acumulado ultrapassou 1,4 petabytes de dados analisados, atingindo inclusive o limite diário definido pela Google Cloud.
Como mecanismo de proteção, o próprio serviço interrompeu novas consultas.
O problema deixou de ser apenas financeiro.
Passou também a afetar a disponibilidade de algumas funcionalidades da plataforma.
A diferença entre ambiente de testes e produção
[17:38] Um dos pontos mais relevantes destacados por André Cruz foi a diferença entre validar uma solução em desenvolvimento e executá-la numa operação real.
Durante os testes, tudo funcionava corretamente.
O motivo era simples.
O ambiente de desenvolvimento possuía apenas uma pequena amostra dos dados existentes.
Em produção, porém, a plataforma precisava pesquisar quase 900 milhões de registos, alterando completamente o comportamento da infraestrutura.
Foi esse cenário que revelou um problema invisível durante todas as validações anteriores.
Como a Inteligência Artificial ajudou novamente
[18:34] Durante a madrugada de domingo para segunda-feira, André Cruz voltou a recorrer à Inteligência Artificial.
Desta vez, não para migrar dados, mas para redesenhar toda a arquitetura de leitura.
Segundo ele, a IA atuou como um excelente parceiro de implementação.
Enquanto André definia a estratégia técnica, a ferramenta acelerava a escrita do código, permitia testar hipóteses rapidamente e reduzia significativamente o tempo necessário para colocar novas soluções em funcionamento.
Mais uma vez, ficou evidente que a velocidade foi proporcionada pela IA.
Já as decisões arquitetónicas continuaram dependentes da experiência humana.
Como a arquitetura foi redesenhada
1. Segmentação das tabelas
[20:01] O primeiro passo consistiu em abandonar a ideia de uma única tabela de auditoria.
A solução passou a utilizar várias tabelas especializadas.
Cada uma delas foi organizada de acordo com os principais padrões de pesquisa realizados pela plataforma.
Foram criadas estruturas específicas para consultas por:
- ID de webhook;
- ID da transação;
- ID da assinatura;
- utilizador responsável;
- outras chaves frequentemente utilizadas.
Essa reorganização reduziu drasticamente a quantidade de dados analisados em cada pesquisa.
2. Pesquisa em duas etapas
[21:57] Mesmo após a segmentação, ainda existia um problema importante.
Os campos JSON permaneciam muito grandes.
Para resolver essa limitação, a equipa implementou uma estratégia em duas fases.
Primeiro eram pesquisados apenas os identificadores dos registos desejados.
Só depois eram carregados os conteúdos completos desses registos.
Essa simples alteração reduziu significativamente o volume de dados transferidos em cada consulta.
3. Limitação temporal das pesquisas
[23:22] Outro ajuste importante foi limitar o intervalo temporal das pesquisas.
Anteriormente, determinadas consultas percorriam praticamente todo o histórico da plataforma.
Com a nova abordagem, as pesquisas passaram a considerar apenas períodos específicos por defeito.
Ao reduzir o número de partições analisadas, o desempenho melhorou consideravelmente e os custos diminuíram ainda mais.
4. Implementação de cache
[24:30] A análise dos logs revelou outro comportamento inesperado.
Alguns clientes realizavam diversas consultas idênticas num intervalo muito curto.
Para evitar leituras repetidas no BigQuery, foi implementada uma camada de cache.
Na prática, isso eliminou inúmeras consultas desnecessárias e reduziu ainda mais o consumo da infraestrutura.
5. Definição de limites de consumo
[25:25] Uma das principais mudanças foi estabelecer limites rigorosos para evitar novos incidentes.
Entre as medidas adotadas estavam:
- limite diário de consumo do BigQuery;
- restrições para consultas excessivamente pesadas;
- mecanismos internos de proteção contra leituras desnecessárias.
Segundo André Cruz, esse tipo de configuração deveria existir em qualquer operação SaaS que utilize serviços cloud pagos por consumo.
O verdadeiro papel da Inteligência Artificial
[26:22] Uma das mensagens mais importantes do episódio foi desfazer a ideia de que a Inteligência Artificial resolve problemas complexos sozinha.
Segundo André Cruz, a IA foi determinante para acelerar a execução técnica.
No entanto, todo o pensamento estratégico permaneceu dependente da experiência acumulada ao longo de décadas trabalhando com tecnologia.
Foi esse conhecimento que permitiu:
- identificar o problema real;
- compreender o comportamento da infraestrutura;
- desenhar uma nova arquitetura;
- validar todas as hipóteses antes da implementação.
Sem contexto, experiência e pensamento crítico, a IA apenas executaria instruções.
Ela não seria capaz de compreender o impacto do modelo de negócio nem antecipar o comportamento real dos utilizadores.
Um erro caro que se transformou num investimento
[28:45] Embora a cobrança de US$ 18.500 tenha causado preocupação inicial, a análise completa mostrou um cenário diferente.
A migração reduziu aproximadamente 92% dos custos de armazenamento.
Como a infraestrutura anterior representava quase US$ 10 mil mensais, o investimento inesperado seria recuperado em poucos meses.
Depois desse período, toda a economia passaria a representar ganho financeiro permanente para a empresa.
Na prática, um erro operacional transformou-se num investimento com retorno extremamente positivo.
Principais lições para empresas SaaS
Este episódio deixou diversos ensinamentos para equipas que trabalham com produtos digitais em crescimento.
Entre os principais destacam-se:
- Arquitetura de leitura é tão importante quanto arquitetura de armazenamento.
- Testes em ambientes reduzidos nunca reproduzem completamente a realidade da produção.
- A Inteligência Artificial acelera a execução, mas não substitui conhecimento técnico.
- Toda infraestrutura cloud deve possuir limites de consumo e mecanismos de proteção.
- Os maiores aprendizados normalmente surgem durante os incidentes mais caros.
Conclusão
[30:41] Ao partilhar este episódio, André Cruz apresentou uma perspetiva pouco comum no universo da tecnologia.
Em vez de esconder um erro operacional, mostrou como decisões difíceis, validações constantes e pensamento estratégico transformaram uma cobrança inesperada num projeto altamente rentável.
O episódio reforçou uma conclusão importante para qualquer empresa SaaS.
A Inteligência Artificial é uma poderosa aliada, mas continua a depender da experiência humana para tomar as decisões que realmente definem o sucesso de uma arquitetura escalável.
Mais do que evitar erros, o objetivo deve ser construir processos capazes de aprender rapidamente com eles e transformar custos pontuais em vantagens competitivas duradouras.
