Usando “Back-of-the-envelope calculations” para projetar sistemas escaláveis

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 DeanGoogle 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.

Em Resumo
  • O problema

    Sistemas bem projetados precisam levar em consideração a carga que precisam suportar. O problema é que, infelizmente, análises exaustivas envolvem muitas variáveis, facilitando enganos.
  • A solução

    Adotar "Back-of-the-Envelope calculations". Trata-se de uma combinação de estimativas de uso com parâmetros conhecidos de performance. Essa técnica a permite ter uma boa ideia do comportamento de uma solução antes mesmo de desenvolvê-la.

Fernando Neiva Paiva

Com mais de 10 anos de experiência, é especialista na organização de times ágeis e na elaboração de soluções inteligentes. Mais do que técnico, tem predileção pelo lado humano das organizações.

Elemar Júnior

Microsoft Regional Director e Microsoft MVP. Atua, há mais de duas décadas, desenvolvendo software e negócios digitais de classe mundial. Teve o privilégio de ajudar a mudar a forma como o Brasil vende, projeta e produz móveis através de software. Hoje, seus interesses técnicos são arquiteturas escaláveis. bancos de dados e ferramentas de integração. Além disso, é fascinado por estratégia e organizações exponenciais.

Talvez você goste também

Carregando posts…

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *