Jean Pierre Lessa e Santos Ferreira, CTO do Grupo Carrefour Brasil, pontua que a escalabilidade de sistemas se decide antes do pico de acesso, e não durante ele. Quem espera o sistema falhar para planejar a expansão paga mais caro, com menos tempo e sob pressão do negócio.
A dificuldade está em acertar o momento. Preparar cedo demais consome orçamento em capacidade ociosa. Preparar tarde demais transforma uma data comercial importante em incidente, com páginas lentas, pedidos perdidos e equipes apagando incêndios em vez de evoluir o produto.
Existe, porém, um intervalo em que a decisão ainda é técnica, e não emergencial. Reconhecê-lo depende de ler os sinais que o próprio sistema emite, de saber quanto tempo cada tipo de expansão leva e de definir o que atacar primeiro.
Quais sinais indicam que a expansão precisa começar?
Uma loja virtual que responde em 300 milissegundos com pouco tráfego e passa a responder em 900 nos horários de pico está avisando algo. A média pode continuar aceitável, mas os percentis altos, como o p95 e o p99, revelam a experiência dos clientes mais afetados.
Esse comportamento costuma vir junto com a saturação de algum recurso. Processadores operando longos períodos perto do limite, filas que demoram a esvaziar e conexões de banco de dados esgotadas indicam que a folga está acabando. Nenhum deles derruba o sistema sozinho, mas todos reduzem a margem para um pico inesperado.
O terceiro sinal vem do negócio, não da infraestrutura. Campanhas planejadas, novas regiões atendidas ou a integração de uma empresa adquirida alteram o volume de uso de forma previsível. Quando esses eventos estão no calendário, o crescimento deixa de ser hipótese e passa a ser prazo.
Quanto tempo antes a preparação deve acontecer?
Jean Pierre Lessa e Santos Ferreira avalia que o prazo de preparação depende menos do tamanho do pico e mais do tipo de mudança que ele exige. Acrescentar instâncias a um serviço sem estado, hospedado em nuvem, leva horas. Separar um banco de dados monolítico leva meses.
Por isso, a pergunta útil não é quando o tráfego vai crescer, e sim qual gargalo é o mais lento de resolver. Se o limite está no banco de dados, a janela precisa ser longa, porque envolve migração, testes de consistência e ajustes nas aplicações que dependem dele.
Uma prática comum é planejar de trás para frente. Parte-se da data do evento e desconta-se o congelamento de mudanças que muitas operações adotam antes de datas críticas. Daí sai o prazo em que a expansão precisa estar pronta e validada em testes de carga.
Por onde começar quando a folga está acabando?
Nem todo gargalo pede a mesma resposta. Antes de ampliar a infraestrutura, convém verificar se o problema está em consultas sem índice, em chamadas repetidas que poderiam usar cache ou em processos síncronos que funcionariam melhor em fila. Esses ajustes liberam capacidade com custo menor.
Jean Pierre Lessa e Santos Ferreira considera que a otimização encontra limite quando o crescimento é estrutural, como na integração tecnológica de operações adquiridas, tema que conduziu no varejo. Nesses casos, o caminho passa por separar responsabilidades e distribuir a carga entre serviços.
A escolha entre crescer verticalmente, com máquinas maiores, ou horizontalmente, com mais instâncias, entra nessa etapa. A primeira é mais rápida, mas esbarra num teto físico e financeiro. A segunda exige que a aplicação rode em várias cópias simultâneas, o que nem sempre acontece em sistemas antigos.
Expansão planejada muda a conversa entre tecnologia e negócio
Tratada com antecedência, a expansão deixa de ser gasto emergencial e entra no planejamento financeiro como qualquer investimento. A tecnologia apresenta alternativas com prazos e valores, e a liderança escolhe com clareza o risco que aceita correr em cada data.
Há também um efeito sobre as equipes. Times fora do regime de urgência têm espaço para documentar decisões, automatizar testes e revisar a arquitetura com calma. Isso reduz a chance de a próxima expansão repetir os atalhos da anterior.
Sob esse olhar, Jean Pierre Lessa e Santos Ferreira resume que a escalabilidade deixa de ser defesa contra falhas e passa a ser condição para crescer. Sistemas preparados antes da demanda permitem aproveitar oportunidades quando surgem, sem que a infraestrutura dite o ritmo das decisões comerciais.
