APRENDER. PRATICAR. EVOLUIR.Distinguir caminho crítico de soma
Considera três chamadas com durações fixas de 40, 90 e 180 milissegundos, mais dez de trabalho após receber os resultados. Se começam juntas, não disputam recursos e todas são obrigatórias, o modelo dá max(40,90,180)+10=190. Se forem sequenciais, dá 320. Estes números não são percentis medidos nem incluem filas, conexões ou limites de concorrência. Desenha as dependências antes de aplicar a fórmula: uma chamada que precisa do resultado de outra não começa ao mesmo tempo. Num serviço fictício de relatórios, a comparação ajuda a formular uma experiência, mas a aprovação precisa de latência observada sob carga representativa e de critérios para resultados parciais.
Declarar a hipótese de independência
Um modelo diferente pergunta pela probabilidade de vinte dependências terminarem dentro do prazo, quando cada uma tem probabilidade 0,99. Só sob a hipótese de independência, e com todas obrigatórias, o resultado é 0,99 elevado a vinte, aproximadamente 81,79%. O laboratório calcula a fração exata com Python; não mediu qualquer serviço. Dependências que partilham base de dados, rede ou limite de recursos podem ter resultados correlacionados. Nesse caso, multiplicar as probabilidades individuais não estabelece a probabilidade conjunta. Usa o cálculo para questionar a expansão do fan-out e pedir dados. Define também se uma resposta incompleta tem utilidade ou se a aplicação precisa de recusar quando falta um resultado obrigatório.
Medir concentração por shard
O modelo de partições tem quatro shards, cada um com capacidade de 300 pedidos por segundo. A distribuição é 700, 100, 100 e 100: a procura total de 1000 cabe aparentemente na capacidade agregada de 1200, mas o primeiro shard recebe mais 400 por segundo do que consegue servir. A capacidade livre dos restantes não migra automaticamente para ele. Se a chave é tenant_id e a organização dominante continua numa única partição, acrescentar shards sem alterar essa distribuição pode manter o problema. Pede dados por chave e partição, avalia subdivisão e custos de consultas cruzadas. Estes cálculos são um modelo; nenhuma implementação de sharding foi executada neste laboratório.
Dimensionar a condição de cache fria
A aplicação fictícia recebe 1000 pedidos por segundo. Com 95% de acertos, o modelo envia 50 à origem. Depois de reiniciar a cache, 20% de acertos enviam 800 à origem, dezasseis vezes a carga anterior. Se a origem tiver um orçamento de 200, a procura calculada é quatro vezes esse limite. Não assumas que o fallback direto preserva a disponibilidade: pode sobrecarregar precisamente a dependência necessária à recuperação. Discute admissão, prioridades, atualização aceitável e degradação com o responsável do serviço. Depois testa a condição de arranque e recuperação. O script apenas calcula os valores; não iniciou uma cache, não mediu capacidade e não validou uma política de aquecimento.
Conservar âmbito e autorização
Dois clientes organizacionais podem ter um relatório com o mesmo identificador local. Uma chave composta apenas por report_id perde essa distinção e pode devolver o conteúdo de outra organização. A revisão deve identificar todas as dimensões que alteram o resultado, incluindo o âmbito organizacional e, quando aplicável, a visibilidade autorizada. Separar chaves não substitui autorização no acesso. Avalia também a sensibilidade dos dados e se uma cache partilhada é adequada. Numa alteração de formato, trata as entradas antigas, a invalidação e a compatibilidade entre versões. Este caso é um exercício de arquitetura com dados fictícios; não representa um incidente observado nem um teste executado contra uma cache real.
Ligar custo, resultado e decisão
Compara duas variantes fictícias que custam 600 na mesma janela e com o mesmo âmbito. A primeira recebe 100000 pedidos e conclui corretamente 90000; a segunda recebe 95000 e conclui corretamente 94000. Dividir pelo número recebido favorece uma leitura diferente de dividir por resultados corretos. Se o objetivo é custo por resultado correto, usa 600/90000 e 600/94000, conservando critérios de qualidade, atualização e prazo. Termina com um registo de decisão que inclua hipótese, evidência, lacunas, responsável e condição de revisão. O guião pode apoiar uma reunião com arquitetura, APS e FinOps, mas essa sessão humana não foi realizada e os números não são custos reais de um fornecedor.
parallel_ms = max(40, 90, 180) + 10 # 190
sequential_ms = 40 + 90 + 180 + 10 # 320
# Probability below assumes independent outcomes:
from fractions import Fraction
all_within_deadline = Fraction(99, 100) ** 20
# Synthetic arithmetic, not a measured service percentile.
origin_warm = 1000 * (1 - 0.95) # 50/s
origin_cold = 1000 * (1 - 0.20) # 800/sUma arquitetura fictícia tem 1200 pedidos/s de capacidade agregada, mas concentra 700 num shard que suporta 300. A margem total esconde uma fila local crescente.
Armadilhas comuns
Somar capacidades incompatíveis, multiplicar probabilidades sem independência, usar o hit rate médio como garantia ou contabilizar pedidos aceites como resultados corretos.
Tópicos relacionados: Monitorização e observabilidade · Load Balancing · Gestão de projetos técnicos
Um cálculo revela uma hipótese a testar. A decisão precisa de medições representativas, critérios funcionais e limites de operação explícitos.
Referência: Performance testing · System design patterns; PostgreSQL18 scoped examples; primary guidance consulted 2026-09-30