Conceitos
Requisitos e estimativa de capacidade
Intuição
Antes de construir uma ponte, o engenheiro pergunta o que ela precisa fazer (carregar carros ou só pedestres?), quantas pessoas vão passar na hora mais cheia e quanto tempo de interdição é aceitável por ano. Depois faz contas rápidas, de cabeça, para saber se o projeto é do tamanho de uma passarela ou de uma rodovia, e anota as suposições que usou para que outros possam discordar delas. Em sistemas é igual: primeiro se combina o que o sistema deve fazer e quão bom ele precisa ser, depois se estima o tamanho do problema, sem precisão, só para acertar a ordem de grandeza.
Como funciona
Requisitos funcionais dizem o que o sistema faz (criar pedido, encurtar URL, redirecionar); requisitos não funcionais dizem quão bem: disponibilidade, latência, durabilidade, consistência e escala. Um SLI (service level indicator) é a métrica medida, como a fração de requisições bem-sucedidas; um SLO (service level objective) é a meta sobre essa métrica. A meta de disponibilidade se traduz em orçamento de indisponibilidade: um ano tem 365 x 24 = 8.760 h, então 99% permite 1% x 8.760 = 87,6 h (cerca de 3,65 dias), 99,9% permite 0,1% x 8.760 = 8,76 h, 99,99% permite 0,01% x 8.760 = 0,876 h = 52,56 min (cerca de 52,6 min) e 99,999% permite cerca de 5,26 min por ano. A estimativa de carga segue a cadeia usuários x ações x bytes. Um dia tem 24 x 3.600 = 86.400 s. Exemplo com suposições declaradas: 10 milhões de DAU (usuários ativos por dia) x 2 escritas por usuário = 20 milhões de escritas/dia; dividido por 86.400 dá cerca de 231 escritas/s de QPS médio. Com razão leitura:escrita de 10:1, são 200 milhões de leituras/dia, cerca de 2.315 leituras/s. O sistema é dimensionado pelo QPS de pico, não pela média: com fator de pico 3x, as escritas chegam a cerca de 694/s e as leituras a cerca de 6.944/s. Para armazenamento, 20 milhões de escritas/dia x 1 KB = 20 GB/dia, x 365 = 7,3 TB por ano, antes de multiplicar pelo fator de replicação (com 3 réplicas, cerca de 21,9 TB). Para banda, QPS x bytes por requisição: 6.944 leituras/s x 1 KB, cerca de 6,9 MB/s, ou cerca de 55 Mbit/s. A latência também é orçada: o alvo ponta a ponta (por exemplo, p99 abaixo de 200 ms) é repartido entre os saltos do caminho (rede, serviço, cache, banco), e os números de ordem de grandeza de cada salto dizem se o orçamento fecha. O resultado é comparado com a capacidade de referência de um componente (por exemplo, um único primary de banco) para decidir se basta escalar verticalmente ou se é preciso cache, fila ou sharding. Cada passo é feito com suposições escritas, para que a conta seja verificável e corrigível.
Na prática
Em entrevistas e em design reviews, a primeira fase é esclarecer requisitos e escala, e a segunda é uma conta de guardanapo que mostra onde está o gargalo: sistemas dominados por leitura pedem cache e réplicas, e sistemas dominados por escrita ou com pico alto pedem fila e particionamento. Referências canônicas: o capítulo sobre service level objectives do livro Site Reliability Engineering do Google (SLI, SLO, SLA e orçamento de erro) e a lista 'latency numbers every programmer should know', popularizada por Jeff Dean, para estimar a latência de cada salto. Boa prática é arredondar de forma conservadora, mostrar a derivação e dizer qual suposição mudaria a decisão, em vez de apresentar um número sem origem.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.