Métricas de capacidade: RPS, conexões, storage, bandwidth e crescimento

Resultado e conexão com a aula anterior

Na aula anterior você transformou uma frase vaga em requisitos, qualidades e restrições verificáveis. Isso responde "o que o sistema faz" e "como ele deve se comportar". Falta uma terceira pergunta, que nenhuma dessas categorias responde sozinha: quanto o sistema precisa aguentar — hoje e daqui a um ano — para que a decisão de arquitetura não seja um chute.

Ao final desta aula, você será capaz de:

1. Converter usuários ativos e ações em RPS médio e RPS de pico, com a mesma disciplina de uma fórmula, não de uma intuição.
2. Calcular bandwidth a partir de payload e RPS, sem confundir bits com bytes.
3. Estimar storage por dia e storage total, considerando retenção e replicação — não só o dado "cru".
4. Projetar crescimento com percentis e intervalo de confiança, e não com um único número otimista.
5. Definir uma margem de headroom e explicar por que dimensionar exatamente para o pico projetado é uma forma de programar o próprio incidente.

O problema: um número errado vira uma decisão de arquitetura errada

Uma estimativa de capacidade não é burocracia — ela é a entrada de toda decisão que vem depois: quantas instâncias, qual tamanho de fila, qual tipo de banco, qual link de rede, qual orçamento de infraestrutura. Errar a estimativa por um fator de 2× já é caro; errar por um fator de 10× é uma categoria de incidente diferente.

Isso não é hipotético. Ao registrar o lançamento de Pokémon GO, o Google SRE Workbook descreve que a equipe fez load test da pilha para até 5× a estimativa mais otimista de tráfego — e mesmo assim a demanda real de RPS chegou a quase 50× a estimativa original. O time tinha feito o trabalho de estimar e testar; o erro não foi preguiça, foi um modelo de demanda desalinhado com a realidade e sem margem suficiente para o desvio. A lição que o próprio relato tira não é "adivinhe melhor da próxima vez" — é ter um método explícito para chegar ao número, e reservar capacidade de sobra para quando o número errar.

Esse é o objetivo desta aula: um método repetível para transformar "quantos usuários" em "quantas requisições por segundo, quantos bytes por segundo e quantos bytes armazenados" — e uma margem que absorve o erro que todo método de estimativa carrega.

Onde essas métricas entram no fluxo de execução

Cada requisição de um usuário percorre um caminho físico: ela chega como uma conexão de rede, carrega um payload, é processada e frequentemente grava um registro que precisa ser guardado por um tempo. As métricas de capacidade não são abstrações soltas — cada uma mede um ponto desse caminho:

• RPS (requests per second) mede a frequência de chegada de trabalho no sistema.
• Bandwidth mede o volume de dados que atravessa a rede por segundo, resultado de RPS × tamanho do payload.
• Storage mede o volume de dados que fica retido depois que a requisição termina.
• Crescimento projeta como essas três métricas mudam ao longo do tempo, para que a capacidade provisionada hoje ainda sirva daqui a alguns meses.

O fluxo tem duas trilhas paralelas que nascem da mesma demanda: tráfego (RPS → bandwidth) e dados (eventos → storage). As duas convergem na projeção de crescimento, porque ambas precisam de margem — headroom — antes de virarem uma decisão de capacidade.

Leitura do fluxo: comece sempre pela demanda de negócio (usuários ativos e ações), nunca por uma tecnologia. Cada seta é uma multiplicação ou soma que você deve saber justificar em voz alta. Se não consegue explicar de onde veio um número, ele é um chute disfarçado de estimativa.

RPS médio e RPS de pico

RPS médio é o ponto de partida: quantas ações relevantes o sistema recebe, em média, por segundo.

RPS médio = (usuários ativos por dia × ações relevantes por usuário) ÷ 86 400 segundos

Esse número sozinho é perigoso, porque tráfego real não é uniforme ao longo do dia. Ele tem um padrão diurno (mais tráfego de dia do que de madrugada), pode ter sazonalidade (fim de mês, feriados) e pode ter eventos de negócio (lançamento, campanha, sorteio). O SRE Workbook recomenda medir a carga o mais próximo possível do cliente para capturar esse comportamento cedo, e insiste que serviços voltados ao usuário devem reservar capacidade de sobra tanto para proteção contra sobrecarga quanto para redundância — não é opcional, é parte do dimensionamento.

Por isso, o número que dimensiona o sistema é o RPS de pico, não o médio:

RPS de pico = RPS médio × fator de pico

O fator de pico combina padrão diurno, sazonalidade e eventos conhecidos. Ele vem de dados históricos (pico/médio observado em produtos comparáveis) quando eles existem, e de uma estimativa conservadora, documentada e revisável quando não existem — nunca de "parece razoável".

Bandwidth: RPS de pico × payload, sem confundir bits com bytes

Bandwidth é o volume de dados por segundo que a rede precisa suportar. A fórmula soma o payload da requisição e da resposta, porque as duas atravessam a rede:

Bandwidth = RPS de pico × (tamanho médio do request + tamanho médio do response)

O resultado dessa multiplicação sai em bytes por segundo. Aqui mora o erro mais comum e mais caro desta aula: provedores de rede, planos de link e ferramentas de monitoramento costumam expressar capacidade em bits por segundo. A RFC 5136 — Defining Network Capacity formaliza a definição de capacidade de um enlace como a quantidade de bits transmitidos com sucesso por unidade de tempo — e destaca explicitamente que "bandwidth" é um termo sobrecarregado, usado de forma inconsistente entre engenheiros de rede, engenheiros elétricos e usuários finais. Se você calcula em bytes e contrata ou lê capacidade em bits sem multiplicar por 8, seu número final erra por um fator de 8× — na direção mais perigosa, a de superestimar a capacidade disponível.

Bandwidth (bits/s) = RPS de pico × tamanho médio do payload (bytes) × 8

Guarde a checagem: sempre que um número de capacidade atravessar uma fronteira entre "o que meu código mede" (geralmente bytes) e "o que o provedor de rede anuncia" (geralmente bits), converta explicitamente e escreva a unidade ao lado do número.

Storage: o que fica depois que a requisição termina

Nem toda requisição grava um registro durável, mas as que gravam definem quanto espaço em disco o sistema consome — e esse consumo cresce todos os dias em que o sistema roda, diferente de RPS e bandwidth, que são medidos por segundo e não se acumulam.

Storage por dia = eventos ou registros gerados por dia × tamanho médio do registro

O ponto onde a maioria das estimativas de storage fica otimista demais é esquecer os multiplicadores que vêm depois do dado "cru":

• Retenção: por quantos dias, meses ou anos o dado precisa ficar acessível — por produto, contrato ou obrigação regulatória.
• Replicação: quantas cópias do dado existem para durabilidade e disponibilidade (réplicas de banco, backups, cópias entre regiões).

Storage total = storage por dia × dias de retenção × fator de réplicas

Um registro de 2 KB parece irrelevante até multiplicar por um milhão de eventos por dia, 400 dias de retenção e um fator de réplicas de 3 — a diferença entre "achei que era pouco" e o disco cheio em produção é exatamente essa cadeia de multiplicações que ninguém escreveu no papel.

Crescimento: projete com percentis, não com um único número

Toda estimativa de capacidade descreve um instante. Sistemas em produção continuam recebendo tráfego amanhã, no mês que vem e no ano que vem — e a capacidade provisionada precisa acompanhar, ou o sistema falha por sucesso: cresceu o suficiente para quebrar a própria infraestrutura.

Projetar crescimento como "vamos crescer 10% ao mês" e multiplicar um único número por doze meses é mais preciso do que não projetar nada, mas ainda esconde o risco real: quão errada essa taxa pode estar? O planejamento de capacidade do Google Cloud Capacity Planner ilustra a alternativa: combinar histórico com um modelo de tendência e sazonalidade, e expressar o resultado como um intervalo de confiança — por exemplo, 50% de probabilidade de a demanda futura cair entre um percentil 25 e um percentil 75, e 90% de probabilidade de cair entre um percentil 5 e um percentil 95. A mesma lógica de percentis que você já usa para latência (p95, p99) se aplica a demanda futura: um único número median esconde a cauda, e é a cauda que estoura a capacidade.

Na prática, sem uma ferramenta de forecasting dedicada, o back-of-envelope consciente é: estime uma taxa de crescimento "esperada" (P50) e uma taxa "pessimista, mas plausível" (próxima de P90–P95) a partir de dados históricos ou de produtos comparáveis, projete os dois cenários e dimensione para o pessimista com uma margem adicional — não para o esperado. É menos preciso que um modelo estatístico formal, mas muito mais honesto do que uma linha reta otimista.

Headroom: por que dimensionar exatamente para o pico projetado falha

Depois de calcular RPS de pico, bandwidth, storage e a projeção de crescimento, ainda falta um passo: reservar margem acima desse número. O SRE Workbook é direto sobre isso — recomenda que serviços voltados ao usuário reservem capacidade de sobra tanto para absorver picos inesperados quanto para manter redundância quando parte da infraestrutura falha, e recomenda configurar autoscaling para manter o sistema longe de gargalos-chave (como CPU), não em cima deles.

Sem headroom, três coisas comuns viram incidente:

• Uma variação normal de tráfego (um dia um pouco mais movimentado que o "pico" estimado) já satura o sistema.
• Perder uma instância, uma zona ou uma réplica reduz a capacidade disponível abaixo da demanda atual, não apenas abaixo de um pico futuro.
• Não sobra espaço para absorver o próprio erro da estimativa de crescimento — e toda estimativa tem erro.

Não existe um percentual universal de headroom; ele depende do custo de errar para menos (degradação, fila, perda de receita) comparado ao custo de errar para mais (capacidade ociosa paga). O que é inegociável é que a margem exista, seja um número explícito e documentado — não "o que sobrou depois de comprar o resto" — e seja revisada quando a demanda real destoar da projeção.

Exemplo resolvido: dimensionar um serviço de pedidos para a Black Friday

Retomando o produto de retirada em loja da aula anterior: ele hoje tem 3.000.000 de usuários ativos por dia (DAU), cada um gera em média 8 ações relevantes ao serviço de pedidos por dia (buscar produto, criar pedido, consultar status, confirmar retirada). O request médio pesa 1,5 KB, a resposta 4 KB. Cada pedido criado gera 3 eventos de auditoria de 2 KB cada, e apenas pedidos criados — não todas as 8 ações — geram esses eventos: são 400.000 pedidos criados por dia. Retenção regulatória de eventos: 400 dias. Fator de réplicas de storage: 3. O produto planeja uma campanha de Black Friday e, com base em campanhas comparáveis, espera um fator de pico de 8× sobre o RPS médio atual. O crescimento histórico é de 8% ao mês (P50), com um cenário pessimista de 15% ao mês (próximo de P95) nos últimos lançamentos.

1. RPS médio: (3.000.000 × 8) ÷ 86.400 ≈ 277,8 RPS

2. RPS de pico (Black Friday): 277,8 × 8 ≈ 2.222 RPS

3. Bandwidth no pico: Payload combinado: 1,5 KB + 4 KB = 5,5 KB = 5.500 bytes. 2.222 × 5.500 × 8 ≈ 97.768.000 bits/s ≈ 97,8 Mbit/s Convertido para o que normalmente se contrata: ≈ 0,1 Gbit/s de link, antes de headroom.

4. Storage por dia e storage total: 400.000 pedidos × 3 eventos × 2 KB = 2.400.000 KB/dia = 2,4 GB/dia 2,4 GB × 400 dias × 3 réplicas ≈ 2.880 GB ≈ 2,9 TB só para os eventos de auditoria retidos, sem contar outras tabelas.

5. Projeção de crescimento em 12 meses (cenário pessimista, P95): (1,15)^12 ≈ 5,35× RPS de pico projetado: 2.222 × 5,35 ≈ 11.888 RPS. Bandwidth projetado: 97,8 Mbit/s × 5,35 ≈ 523 Mbit/s. (Simplificação assumida: aplicar o multiplicador final a um único mês de pico. Um modelo mais rigoroso projetaria o crescimento mês a mês, porque o volume acumulado de storage cresce com a soma da série, não só com o valor do último mês — mas o back-of-envelope já é suficiente para decidir a ordem de grandeza da capacidade a reservar.)

6. Headroom: Aplicando uma margem de 40% sobre o cenário pessimista projetado — decisão de produto, documentada, revisável —: 11.888 × 1,4 ≈ 16.643 RPS, 523 Mbit/s × 1,4 ≈ 732 Mbit/s (arredondado para um link de 1 Gbit/s, a próxima capacidade padrão disponível).

O resultado não é "compre mais servidor". É uma tabela de números defensáveis — RPS, bandwidth, storage, crescimento e margem — que agora pressiona decisões concretas de arquitetura: quantas instâncias atrás do load balancer, que tipo de armazenamento para os eventos de auditoria, que categoria de link contratar. Essas decisões são o assunto das próximas aulas desta trilha.

Abordagens insuficientes

"Estimamos pela média de tráfego do mês passado." A média esconde o pico, e é o pico que precisa de capacidade. Um sistema dimensionado pela média falha exatamente no momento de maior importância para o negócio — hora de maior venda, lançamento, campanha.

"Calculamos bandwidth e comparamos direto com o plano do provedor." Sem checar se a métrica está em bits ou bytes, esse número pode estar errado por 8×. É barato conferir a unidade; é caro descobrir o erro sob carga real.

"Somamos o tamanho dos registros e pronto, isso é o storage." Sem multiplicar por retenção e réplicas, essa conta descreve o dado em um instante, não o espaço em disco que ele vai ocupar ao longo do tempo em um sistema replicado — o erro típico é subestimar por um fator de dezenas a centenas de vezes.

"Projetamos crescimento como uma linha reta otimista." Um único número de crescimento esconde a variância real do negócio. Quando a demanda real fica acima da linha otimista — o que acontece com frequência maior do que se espera —, a capacidade provisionada já nasceu insuficiente.

"Dimensionamos exatamente para o pico calculado." Isso trata a estimativa como se fosse exata e ignora falhas de infraestrutura. Qualquer desvio para cima, ou qualquer redução de capacidade disponível (uma instância fora do ar), vira degradação ou indisponibilidade.

Prática guiada: capacidade para um sistema de chat

Perguntas de entrevista e revisão

"Como você estima RPS para um sistema novo, sem dados históricos?" "Parto de usuários ativos esperados e ações por usuário, documentando cada suposição. Sem histórico próprio, uso benchmarks de produtos comparáveis para o fator de pico e assumo o cenário mais conservador plausível, não o mais otimista. Documento a suposição para revisar assim que houver dado real."

"Por que bandwidth em bits e não em bytes?" "Porque minha conta interna normalmente está em bytes, mas provedores de rede e links costumam anunciar capacidade em bits por segundo. Converto explicitamente multiplicando por 8 e mantenho a unidade escrita ao lado de cada número para não confundir os dois."

"Como você decide o percentual de headroom?" "Comparo o custo de errar para menos — degradação, fila, indisponibilidade, perda de receita — com o custo de errar para mais — capacidade ociosa paga. Não existe número universal; documento a decisão e a revejo quando o tráfego real diverge da projeção."

"O que muda entre estimar storage para um banco relacional e para um data lake de eventos?" "A fórmula de base é a mesma — registros × tamanho × retenção × réplicas —, mas a granularidade muda: eventos de um data lake tendem a ter volume muito maior e retenção mais longa, então o efeito de esquecer replicação ou retenção nessa conta é proporcionalmente mais caro."

Recupere da memória: 10 questões

Recupere da memória: 10 questões

RPS médio é calculado a partir de:

Usuários ativos, ações por usuário e segundos do período.Apenas o número de servidores disponíveis.O tamanho médio do payload de resposta.

Por que dimensionar pela média de tráfego é arriscado?

A média esconde o pico, que é quando a capacidade realmente é testada.A média é sempre maior que o pico real.A média não pode ser calculada sem um APM.

O fator de pico deve vir de:

Uma suposição confortável, ajustada depois se necessário.Dados históricos comparáveis ou uma estimativa conservadora documentada.O valor padrão usado por qualquer sistema.

Bandwidth é calculado multiplicando RPS de pico por:

O tempo médio de resposta do serviço.O número de réplicas do banco de dados.O tamanho combinado de request e response.

Um erro clássico ao calcular bandwidth é:

Confundir bits com bytes ao comparar com a capacidade do link.Usar RPS de pico em vez de RPS médio.Medir o payload em quilobytes.

Storage total, além do volume de dados por dia, também depende de:

O tempo de resposta médio da API.Retenção e fator de réplicas.O número de instâncias de aplicação.

Projetar crescimento com percentis, em vez de um único número, serve para:

Simplificar a apresentação para stakeholders não técnicos.Expor o risco de a demanda real superar a estimativa otimista.Evitar a necessidade de revisar a estimativa depois.

Headroom existe principalmente para:

Reduzir o custo de infraestrutura no curto prazo.Absorver variação de tráfego e perda de capacidade sem virar incidente.Substituir a necessidade de medir RPS de pico.

No relato do lançamento de Pokémon GO citado no SRE Workbook, o principal aprendizado destacado é:

Nunca fazer teste de carga antes de um lançamento.Ter um método de estimativa e reservar margem para quando ele errar.Sempre estimar exatamente para o pico esperado, sem folga.

RPS e concorrência de conexões são:

O mesmo número, expresso de formas diferentes.Conceitos relacionados, mas diferentes — concorrência depende também da duração da conexão.Métricas usadas apenas em sistemas de streaming.

Próximo passo e referências

Pegue um sistema real que você conhece — mesmo que os números sejam aproximados — e calcule RPS médio, RPS de pico, bandwidth e storage total dele, com as suposições explícitas ao lado de cada número. Traga essa conta ao agente para revisão antes de seguir. Na próxima aula, esses números ganham uma ferramenta formal — Lei de Little, percentis de latência e Lei de Amdahl — para conectar tráfego, concorrência e o efeito real de paralelizar trabalho.

Leitura primária recomendada: Google SRE Workbook — Managing Load. Consulte também RFC 5136 — Defining Network Capacity e Google Cloud — Capacity Planner overview.

Pesquisa: registro de fontes da aula · Diagrama: da métrica de negócio à decisão de capacidade.