Como incluir capacity planning no calendário de produto

O pager não deveria ser a primeira confirmação de que a capacidade acabou. O sinal costuma aparecer antes: em uma campanha prevista, numa mudança de preço, numa integração que amplia o uso ou numa projeção comercial que ainda está sendo tratada como assunto de outra área.

Para um CTO e para quem sustenta a arquitetura, o problema não é tentar prever o futuro com precisão impossível. O problema é deixar a incerteza sem dono. Quando a previsão não chega ao planejamento técnico, a organização troca uma conversa desconfortável por deploys apressados, degradação para clientes e mais noites de plantão para o time.

Transforme previsão em um calendário de capacidade #

Uma previsão de receita, aquisição ou uso não informa diretamente quantas réplicas criar. Ela informa uma hipótese de demanda que precisa ganhar unidades, janelas de tempo e condições de falha. “Mais clientes no trimestre” é amplo demais; “mais tentativas de checkout por minuto durante uma promoção” já permite discutir filas, banco, limite de terceiros e caminho crítico.

Comece reunindo o que já existe fora da engenharia: datas de lançamento, contratos em negociação, campanhas, migrações, mudanças de plano e recursos que alteram o comportamento do produto. Cada evento relevante entra no calendário, mesmo quando o intervalo previsto é grande. A precisão vem depois; a visibilidade precisa vir primeiro.

Na prática, uma capacidade planejada não é uma promessa de que a carga chegará exatamente como descrita. É uma decisão explícita: se esta hipótese se confirmar, qual parte do sistema precisa estar pronta antes, qual margem faz sentido e quem volta para revisar a decisão? Capacidade vira risco gerenciável quando a previsão tem data, hipótese e responsável.

flowchart LR
    A[Previsão comercial ou de produto] --> B[Hipóteses de demanda]
    B --> C[Calendário de capacidade]
    C --> D[Restrições e tempo de preparação]
    D --> E{Data de revisão}
    E -->|Hipótese mudou| B
    E -->|Risco confirmado| F[Ação reversível]
    F --> G[Observação e próxima revisão]

O diagrama não substitui a conversa entre produto, comercial e engenharia. Ele torna a dependência visível: uma mudança na previsão deve mover uma hipótese, uma data de revisão ou uma ação — não ficar perdida em uma apresentação que ninguém consulta durante um incidente.

Desenhe a forma da demanda, não só o volume #

Uma média mensal pode parecer tranquila e ainda esconder o período que derruba o sistema. Capacidade responde à forma da carga, não apenas ao total: concentração em determinados horários, rajadas de escrita, leituras repetidas, tamanho de payload, concorrência e dependências externas mudam o que realmente limita o serviço.

Pergunte qual comportamento cada evento tende a criar. Uma campanha pode concentrar acessos em poucas horas. Uma nova funcionalidade pode aumentar consultas por sessão. Uma integração pode introduzir picos irregulares, retries e mais chamadas para uma API externa. A mesma quantidade de usuários pode custar muito diferente conforme o caminho que percorrem.

Isso exige ligar a previsão a uma unidade que o sistema reconhece. Pode ser requisições em uma rota, mensagens em uma fila, jobs concorrentes, conexões abertas ou operações de escrita. Escolha a unidade do gargalo, e não a métrica que fica mais fácil de apresentar em uma reunião.

Também vale separar o que é hipótese de negócio do que é inferência técnica. “A campanha terá adesão” é uma hipótese comercial; “o banco aceitará esse padrão de escrita sem aumentar a latência” é uma hipótese técnica. Misturar as duas cria falsa certeza, porque uma decisão de arquitetura parece validada quando só a projeção comercial foi discutida.

Diferencie crescimento contínuo de mudança brusca #

Nem toda elevação de demanda pede a mesma resposta. Crescimento estável, evento concentrado e mudança de modelo têm horizontes, sinais e ações muito diferentes; tratá-los como uma única categoria costuma produzir excesso de infraestrutura em um caso e preparação insuficiente no outro.

Situação de demanda	Forma que importa	Restrição a acompanhar	Tempo de preparação	Primeira ação sensata
Crescimento estável	aumento gradual da carga sustentada	custo recorrente, banco, throughput de workers	ciclos de planejamento e revisão	medir a tendência e remover o próximo limite conhecido
Pico por evento ou prazo	concentração de tráfego em uma janela curta	concorrência, fila, rate limit e dependências	antes da janela do evento	definir proteção, degradação aceitável e rollback
Mudança de modelo ou uso	alteração do caminho crítico e do custo por operação	writes, tamanho de dados, fan-out e chamadas externas	antes de liberar a mudança amplamente	testar o caminho novo com limites e adoção progressiva

No crescimento estável, o risco costuma aparecer como uma inclinação: capacidade e custo deixam de acompanhar a demanda ao longo do tempo. O pagamento é contínuo, então decisões permanentes — como revisar uma consulta, repartir uma carga ou ajustar retenção — podem fazer sentido se o diagnóstico apontar para elas.

Num evento concentrado, a pergunta muda. Você talvez não precise redesenhar o sistema para uma janela curta, mas precisa saber qual proteção entra em ação quando a carga chega: fila, limite por cliente, cache onde ele preserva correção, degradação de uma função secundária ou expansão temporária. O cliente paga primeiro pela espera, e o time de plantão paga depois pela recuperação se esses limites não foram escolhidos antes.

Já uma mudança de modelo é mais traiçoeira porque pode parecer crescimento comum no começo. Um novo fluxo de uso pode multiplicar leituras, criar fan-out, aumentar o volume armazenado ou transformar um endpoint antes barato em caminho crítico. A alteração é de comportamento, não só de escala, portanto o calendário precisa marcar a data da mudança e não apenas a meta comercial associada a ela.

Registre restrições e o tempo que elas exigem #

Planejamento de capacidade falha quando vira uma lista genérica de “melhorias de performance”. Uma restrição útil tem mecanismo e antecedência: qual componente limita, como o limite aparece, qual sinal avisa antes do impacto e quanto tempo é necessário para mudar a situação com segurança.

Pense em cadeia, não em máquina isolada. A aplicação pode ter CPU disponível enquanto uma fila cresce porque um consumidor está lento. O banco pode ter folga enquanto uma dependência externa aplica rate limit. Um cache pode baixar leituras e, ao mesmo tempo, esconder uma consulta ruim que continuará cara quando houver invalidação. O gargalo é o ponto que transforma demanda em atraso, não necessariamente o gráfico mais alto do dashboard.

Para cada restrição, anote a ação possível e sua antecedência real. Algumas decisões podem ser feitas em horas, como limitar uma rota ou reduzir concorrência de um job. Outras dependem de migração de dados, revisão de contrato, teste de recuperação ou mudança de fornecedor. Tempo de preparação é parte da capacidade, porque uma solução que chega depois do pico não é capacidade disponível.

Vale incluir dependências que não pertencem à sua infraestrutura. Limites de API, provisionamento de conta, aprovações internas, janelas de mudança e conhecimento concentrado em uma pessoa também podem atrasar a resposta. Escalar não é apenas adicionar recurso computacional; é garantir que a organização consegue tomar e executar a decisão antes de ficar sem opções.

Essa leitura também ajuda a discutir custo com mais honestidade. A relação entre aumento de tráfego e custo de nuvem mostra por que ampliar infraestrutura sem entender o caminho de demanda pode só tornar uma ineficiência mais cara. O custo não é um sinal isolado de crescimento saudável quando cada operação começa a consumir mais trabalho do sistema.

Prefira ações que preservem opções #

Nem toda previsão justifica uma mudança estrutural. A melhor primeira decisão costuma ser reversível, especialmente quando a hipótese comercial ainda está aberta: liberar por etapas, limitar um fluxo específico, preparar capacidade temporária, observar a resposta e decidir de novo com evidência melhor.

Isso não significa adiar tudo. Significa escolher o menor passo que reduz o risco conhecido sem fingir que a previsão é certeza. Por exemplo, preparar uma fila pode proteger uma dependência contra rajadas; só que ela também troca falha imediata por atraso acumulado e exige saber quando a fila deixou de ser amortecedor para virar incidente. Toda proteção desloca uma obrigação operacional para algum lugar.

Ações permanentes pedem um nível diferente de convicção. Repartir dados, substituir um componente central ou alterar garantias de consistência pode resolver uma limitação real, mas cobra complexidade de operação e desenvolvimento depois. Quem constrói e mantém o sistema paga por escolhas irreversíveis, mesmo quando a decisão parece barata no diagrama inicial.

Por isso, transforme decisões grandes em uma sequência de pontos de verificação. Primeiro, confirme que a restrição é a que você imagina. Depois, aplique uma medida que seja observável e reversível. Só então decida se o padrão de demanda justifica uma mudança de arquitetura. O calendário não elimina o trade-off; ele impede que o trade-off seja feito às pressas.

Se a discussão já envolve crescimento de demanda, latência, filas e limites de dependências, a prática de scaling de sistemas começa por tornar esses vínculos explícitos antes de escolher tecnologia. A decisão útil é a que conecta risco operacional a uma ação com prazo, não a que produz uma lista longa de ferramentas possíveis.

Mantenha uma revisão curta e contínua #

Um calendário de capacidade não deve virar documento que só reaparece quando algo quebra. A rotina precisa ser mais leve que o incidente, ou ela será abandonada assim que a pressão do roadmap aumentar.

Defina revisões ligadas a eventos reais: antes de uma campanha, antes de liberar uma mudança que altera uso, depois de uma variação importante na demanda e em um ciclo regular que caiba na operação do time. Não há cadência universal; o intervalo depende de quão rápido produto, uso e infraestrutura mudam juntos. A frequência correta é a que permite agir antes do prazo das suas restrições.

Em cada revisão, percorra poucas perguntas: o que mudou na previsão, qual hipótese perdeu validade, que restrição se aproximou, que ação ainda é reversível e quem toma a próxima decisão? Quando nada mudou, registre isso também. Uma hipótese revisada e mantida é melhor que uma promessa esquecida, porque deixa claro que alguém olhou para o risco.

Evite converter a reunião em relatório de todos os dashboards. A finalidade não é comprovar que o time monitora bastante; é decidir se o calendário ainda representa o sistema e o negócio. O resultado da revisão deve ser uma ação, uma data ou uma hipótese atualizada, não uma coleção de gráficos sem consequência.

Perguntas frequentes #

Como planejar capacidade se a previsão comercial é incerta? #

Você não precisa esperar uma previsão exata para começar. Registre intervalos e condições de mudança: o que você acredita hoje, o que faria essa hipótese mudar e quando será reavaliada. A incerteza fica perigosa quando é escondida como se fosse compromisso técnico.

Isso vale para um sistema pequeno? #

Vale, só que o artefato pode ser bem menor. Um calendário simples com eventos, restrições e responsáveis já evita que uma mudança previsível apareça como surpresa; sistemas pequenos também têm dependências, limites e pessoas de plantão.

Quando faz mais sentido adicionar capacidade em vez de otimizar? #

Adicionar capacidade é adequado quando compra tempo de forma clara e não mascara um limite que continuará crescendo mais rápido que a demanda. Se a causa ainda é desconhecida, amplie com cautela e preserve a investigação, porque escalar um caminho ineficiente apenas aumenta o custo de adiar o diagnóstico.

Com que frequência o calendário deve ser revisado? #

Revise antes de eventos relevantes e em uma cadência compatível com o tempo necessário para agir. A referência não é uma cerimônia fixa, mas o prazo de preparação da restrição mais próxima: se a resposta leva semanas, descobrir o risco na semana do evento já é tarde.

Abra o calendário de capacidade agora e escolha o próximo evento de produto ou comercial. Escreva a hipótese de demanda, a primeira restrição que ela pode pressionar, o tempo de preparação e uma data de revisão; se não for possível preencher um desses campos, essa ausência já é o primeiro risco a investigar.