Aplicação de dados no modo sobrevivência

Nem sempre temos o orçamento ideal para construir uma aplicação de dados, às vezes parece aquela compra no mercado de final de mês, fazer muito com pouco.

Quando você está lidando com sellers do país inteiro, catálogo amplo, frota veicular em escala nacional e múltiplas fontes externas, o instinto inicial é pensar: "preciso de mais máquina". Só que em modo low cost, a pergunta muda completamente. Não é "quanto recurso eu tenho?", é "como faço isso caber onde estou?".

E aí começa a engenharia de eficiência.

Em ambiente serverless, você não tem processo rodando 24/7 esperando terminar uma tarefa gigantesca. Você tem tempo limitado, memória limitada e execução efêmera. Isso obriga a desenhar pipelines que pensam pequeno — mesmo quando o problema é grande.

A primeira regra do low cost é fragmentação inteligente.

• Nada de processar milhões de registros de uma vez.
• Tudo vira batch controlado;
• Batch com checkpoint explícito;
• Checkpoint salvo em tabela simples, última chave processada registrada com clareza.

Se a função morre no meio, ela recomeça exatamente de onde parou. Não do zero. Não em "talvez". Precisão economiza CPU, tempo e dinheiro.

Retry também precisa ser econômico. Não é sobre insistir infinitamente. É sobre classificar erros. Timeout? Retry com backoff. Erro estrutural? Loga e segue. Falha irreversível? Marca e não insiste. Cada tentativa desnecessária custa execução.

Crawler em modo low cost exige ainda mais cuidado. Você não pode disparar centenas de requisições simultâneas porque não tem cluster para sustentar isso — e também não quer ser bloqueado. A estratégia vira cadência: ritmo humano, espaçamento coerente, limitação de concorrência. Menos requisições, mas melhor planejadas.

E como lidar com respostas em HTML, JS e JSON sem infraestrutura pesada?

• Parser leve. Extração cirúrgica.
• Nada de engine de renderização headless se não for indispensável.
• Sempre que possível, identificar endpoint oculto que retorne JSON direto em vez de raspar DOM completo.

Particionamento deixa de ser otimização avançada e vira mecanismo de sobrevivência. Separar por UF, por ano, por tipo — qualquer critério que reduza escaneamento completo — já derruba custo de consulta. Indexação precisa ser estratégica. Índice só onde há filtro real. Índice só onde há ordenação frequente. Índice demais encarece escrita e consome espaço. Índice de menos encarece leitura. Em modo econômico, cada índice tem que justificar a própria existência.

E aí entra a grande virada: abandonar OFFSET.

Paginação tradicional escala mal porque precisa contar e pular registros.

Keyset pagination navega por cursor.

Menos trabalho para o banco, menos tempo de execução, menos custo. Outra economia estrutural está no front-end.

Nada de cinco micro chamadas para montar uma tela. Cada chamada é latência, é cold start, é custo. Centralizar consultas em uma única RPC bem estruturada reduz drasticamente round-trips. Uma resposta consolidada pode ser consumida por múltiplas funções do front, desde que tipada corretamente. Tipagem precisa evita retrabalho, evita parsing duplicado, evita consultas adicionais "só para conferir".

Modo low cost também exige aceitar que nem tudo precisa ser real-time. Atualizações podem ser assíncronas. Agregações podem ser materializadas periodicamente. Cálculos pesados podem rodar fora do fluxo principal. Pré-processar é mais barato do que recalcular toda vez.

Consolidação de base é outro ponto crucial. Dados sujos custam caro porque geram consultas complexas. Normalizar, padronizar, criar colunas computadas, armazenar versões já tratadas — tudo isso reduz carga futura. Cada limpeza feita uma vez evita milhares de transformações repetidas.

No fim, trabalhar com dados gigantescos em modo low cost ensina uma lição brutal:

• Escala não é sobre ter mais infraestrutura, é sobre fazer menos desperdício.
• Cada requisição precisa ter propósito;
• Cada índice precisa ter função;
• Cada batch precisa ter limite;
• Cada retry precisa ter critério.

Infra enxuta obriga arquitetura boa.

E quando o sistema cresce mantendo custo controlado, isso não é sorte. É consequência de ter projetado eficiência como princípio, não como remendo posterior.