A boa engenharia de software ajuda a suportar mudanças de escala, preservando a eficiência, ao longo do tempo. Entretanto, tudo começa com um bom “primeiro design”. Ou seja, uma organização de componentes capaz de suportar a demanda inicial, sem desperdícios nem descuidos. 

Evidentemente, ninguém deseja projetar um sistema que “não pare de pé”. Por outro lado, recursos computacionais podem custar caro e, se mal aproveitados, acabam consumindo recursos financeiros valiosos.

De forma inadvertida, é relativamente fácil “gastar demais” construindo soluções muito mais sofisticadas do que as exigidas pela demanda inicial. Principalmente, se a escala não for claramente definida durante o projeto da arquitetura. O problema é que, infelizmente, análises exaustivas envolvem muitas variáveis, facilitando enganos.

Ainda mais grave que sistemas desperdiçando recursos são as falhas para suportar a demanda decorrentes de infraestruturas mal dimensionadas. Infelizmente, não é raro ver sistemas que não aguentam o “peso do ambiente produtivo”, causando prejuízos difíceis de recuperar.

Jeff Dean – Google Senior Fellow, um dos responsáveis pelo motor de busca da empresa,  BigTable, MapReduce e ProtocolBuffers – defende a utilização da técnica simples chamada “Back-of-the-Envelope calculations”. Trata-se de uma combinação de estimativas de uso com números que todo programador deveria saber. Ela permite ter uma boa ideia do comportamento de uma solução antes mesmo de desenvolvê-la.

Um bom ponto de partida, segundo Dean, ao projetar uma API, seria estimar quantas requisições os principais endpoints vão ter que atender (importante, também, para o estabelecimento de Rate Limiters). Daí, considerando horários comuns de consumo, é possível inferir quantas requisições precisam ser suportadas por hora, minuto e segundo balizando o throughput ideal. Adicionadas às margens de segurança, tem-se uma boa ideia de dimensionamento de infraestrutura, frente a arquitetura.

O custo computacional e de tempo para o atendimento de cada requisição também pode ser calculado considerando operações como busca e leitura de dados em dispositivos de armazenamento, transferência de dados na rede, compactação e etc. Daí, projetando o volume de requisições esperadas, pode-se avaliar a eficiência de uma solução proposta.

Em uma palestra em que Dean conta um pouco da trajetória da arquitetura do sistema de buscas da Google, ele demonstra a eficácia da técnica para projetar um sistema de thumbnails (aliás, esse é um desafio clássico em entrevistas de System Design para grandes companhias).

Oren Eini (Ayende), fez uso dessa técnica em um post de uma série discutindo o desafio de reconstruir uma rede social como o twitter.

A ideia de “Back-of-the-envelope calculations”, que em bom português seria algo como “conta de padeiro”, é utilizar cálculos simples para fundamentar a tomada de decisões técnicas. Funciona para a Google, provavelmente funcionará também para sua empresa. É uma solução simples, talvez até em demasia, mas é “mais do que o nada” que parece ser o padrão comum nas organizações.