Planejamento de capacidade em um guardanapo

Antes de ler uma única linha de arquitetura de um sistema novo, eu quero ver o guardanapo. Não uma planilha, não um teste de carga. Um punhado de números, multiplicados entre si, que dizem mais ou menos qual é o tamanho da coisa. Se o time não consegue produzir isso, a arquitetura é um chute vestido de plano.

De números por dia para números por segundo

Gente de negócio pensa em dias e meses. Sistemas vivem em segundos. A conversão é o truque inteiro.

Um dia tem 86.400 segundos. Arredonde para 100.000 e dá para fazer de cabeça: um milhão de requests por dia são uns 10 por segundo na média. Dez milhões são 100 por segundo. Essa média engana, porém, porque o tráfego não é plano. Um produto de consumo típico faz 3x a média no pico; uma ferramenta B2B usada em horário comercial em um único fuso, mais perto de 5x; algo com evento marcado, uma promoção, uma menção na TV, 10x ou mais. Projete para o pico, e anote qual multiplicador você escolheu.

Então: um app de agendamento para 2.000 clínicas, cada uma fazendo 300 agendamentos por dia, são 600.000 agendamentos por dia, uns 7 por segundo na média, talvez 35 por segundo no pico, e cada agendamento pode disparar 10 leituras. São 350 leituras por segundo no pico. Uma única instância de Postgres em hardware decente aguenta vários milhares de queries simples por segundo. Esse sistema não precisa de sharding. Precisa de índices.

Armazenamento cresce em linha reta, até que não

Armazenamento é bytes por registro vezes registros, depois vezes crescimento. Uma linha de agendamento com alguns ids, timestamps, um status e uma observação tem talvez 500 bytes com índices. 600.000 por dia são 300 MB por dia, uns 9 GB por mês, 110 GB por ano. Confortável. Agora adicione um log de auditoria de cada mudança de estado, com 1 KB cada, cinco mudanças por agendamento. São 3 GB por dia, 1 TB por ano, e de repente política de retenção vira decisão de arquitetura, não detalhe.

Esse é o padrão: a tabela principal raramente é o problema. Logs, eventos, anexos e qualquer coisa com fan-out são o que enche disco. Faça a multiplicação para toda tabela que tem fan-out.

Banda e memória, mesmo método

Banda: tamanho da resposta vezes requests por segundo. Um payload JSON de 50 KB a 350 rps são 17,5 MB/s, uns 140 Mbps. Tranquilo para um servidor, doloroso se atravessa a conta de egress da nuvem. Memória: o working set, ou seja, as linhas que estão realmente quentes, precisa caber em RAM para o banco ser rápido. Os agendamentos de hoje em todas as clínicas são uma fração minúscula dos 110 GB. É por isso que o sistema continua rápido mesmo com a tabela crescendo.

O objetivo é a ordem de grandeza

Nenhum desses números vai estar certo. Não é esse o ponto. O guardanapo diz se você está construindo para 10 rps ou 10.000, para 10 GB ou 10 TB, e esses são sistemas diferentes com orçamentos diferentes. Errar por 2x não muda nada. Errar por 100x significa que você escolheu a arquitetura errada.

Então a coisa mais valiosa no guardanapo não é um número, é saber de qual número você tem menos certeza. Quantidade de clínicas? Agendamentos por clínica? O fan-out de leituras por agendamento? Ponha uma estrela ao lado. Essa é a premissa a validar primeiro, com dados reais, antes de se comprometer com infraestrutura.

Anote, e depois volte

Coloque o guardanapo no repositório. Um arquivo markdown com as premissas, os multiplicadores e a data. A cada seis meses, ou depois de qualquer surpresa, compare com as métricas reais. A diferença entre o que você assumiu e o que aconteceu é a revisão de arquitetura mais honesta que você vai ter na vida, e custa uma hora.