
Uma parte geralmente esquecida, embora fundamental, do projeto de sistemas de alto desempenho é o planejamento da capacidade. Particularmente, não prestei muita atenção a esse tópico no passado. Eu tinha a tendência de pensar nisso apenas em um estágio muito inicial de projeto de sistemas e pensei que só era valioso para sistemas em grande escala.

Na verdade, o capacity planning é um exercício incrivelmente informativo. Ele pode ajudá-lo(a) a entender a viabilidade de um projeto específico e também pode sugerir opções melhores. Abordá-lo como parte do processo de design em qualquer mudança considerável - "considerável" definido como uma função de como a mudança afeta a escala relativa do sistema existente - pode ser extremamente útil.

Dito isso, pensei em compartilhar alguns dos fundamentos do capacity planning para design de sistemas.

### Esclareça o escopo do design

Se você estiver construindo um novo sistema do zero ou introduzindo mudanças, o processo usual é entender o que o software deve fazer. **Compreender [requisitos funcionais](https://en.wikipedia.org/wiki/Functional_requirement), como quais recursos são necessários, e [requisitos não funcionais](https://en.wikipedia.org/wiki/Non-functional_requirement), como restrições que o sistema deve obedecer** são um bom lugar para começar. Um exemplo de requisito funcional é adicionar upload de vídeo a uma postagem/feed de mídia social que só oferece suporte a imagens. Um requisito não funcional pode ser a necessidade que esses vídeos funcionem em conexão 2g.

**Depois de entender o que a mudança acarreta, explore suas características.** Por exemplo, observe as proporções de leitura versus escrita. Sistemas diferentes precisarão de otimizações diferentes devido a essas características. Por exemplo, um feed de notícias provavelmente terá mais leituras do que escritas e um aplicativo de bem-estar que rastreia sua atividade enquanto se exercita provavelmente será o contrário.

Outro conjunto de características que afetará o exercício de capacity planning é **compreender como os requisitos não funcionais afetam storage e bandwidth.** Por exemplo, para um aplicativo de mensagens, escolher a persistência local no cliente em vez do servidor para mensagens afetará drasticamente o investimento em armazenamento. No entanto, ele também terá seu próprio conjunto de desafios ao sincronizar dados entre dispositivos.

Neste estágio, esclarecer o que importa ajudará na definição dos melhores trade-offs e, potencialmente, simplificará a implementação.

### Estime algumas das opções

Depois de esclarecer o escopo, você está pronto para passar para algumas estimativas. Neste estágio, você provavelmente tem uma ideia aproximada de quais recursos escolher para estimativa. **Sua medida inicial para quantificar a capacidade é geralmente uma taxa de transferência (throughput) presumida**, inferida de um recurso semelhante ou outro número, como usuários ativos diariamente.

Em primeiro lugar **faça uma estimativa aproximada de quanto custa um request em bytes.** Arredondar para cima é uma boa ideia para manter os números conservadores. Estimativas para texto são simples pois você pode assumir um conjunto de campos e seus tamanhos em bytes. Para armazenamento de objetos, como imagens ou vídeos, pense em versionamento, por exemplo, o tamanho médio de uma miniatura x tamanho inteiro, ou vídeo em 480p x 1080p. Observe como isso interage com os requisitos não funcionais e quais opções você tem disponíveis para cumprir a especificação.

**Depois de saber quanto custa cada registro, pense em bandwidth por operação.** Pense em como você pode reduzir potencialmente a quantidade de dados enviados nos dois sentidos: cliente para servidor e servidor para cliente. Especialmente para leituras, você geralmente tem oportunidades de economia. Por exemplo, em vez de buscar um registro completo, com todos os campos, todas as vezes, você provavelmente pode enviar uma fração do conteúdo do servidor em alguns momentos. Exemplos disso são truncar conteúdo ou renderizar versões. Resumindo, nem toda interação precisará do registro inteiro, então você pode fatorar esse aspecto e descontar dos cálculos de acordo com o comportamento esperado.

A partir daí, é apenas matemática de bytes e [back of the envelope calculations](http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html). **Com o tamanho médio de registro por operação, você tem estimativas** e pode entender trade-offs para diferentes opções de design.

### Busque oportunidades de otimização

Em seguida, otimização. **Uma oportunidade muito comum para a otimização do armazenamento é definir a retenção de dados.** Nem todos os sistemas precisam - ou mesmo podem, devido à compliance - manter todos os dados para sempre. Uma oportunidade típica é examinar a granularidade dos dados, por exemplo, agregar dados por uma dimensão, como por exemplo tempo ou usuário. Especialmente em grande escala, uma política de retenção de dados apropriada pode melhorar drasticamente o desempenho de sistemas e economizar custos.

Outra oportunidade para reduzir a sobrecarga é caching. **Para sistemas read-heavy, geralmente, uma pequena parte do conteúdo obtém uma quantidade desproporcional de leituras**, e o armazenamento em cache pode reduzir drasticamente bandwidth nesses casos. Há uma infinidade de maneiras de explorar a otimização de leituras, como carregar conteúdo via lazy loading com base no que está na janela de visualização, fazer uso de CDN (content delivery network), melhorar gradativamente a qualidade de vídeo/áudio ao longo do tempo de engajamento do usuário e assim por diante. Eles também dependem muito de requisitos não funcionais.

Da mesma forma, você pode **aproveitar do uso de cache para sistemas write-heavy como uma forma de reduzir as necessidades de capacidade de armazenamento**. Por exemplo, em uma arquitetura baseada em eventos time-series, omitir gravações onde não há mudança de estado. Sensores de leitura de temperatura que enviam atualizações em um intervalo de tempo fixo para um servidor são um excelente exemplo disso. As temperaturas não tendem a mudar drasticamente em um curto espaço de tempo, portanto, você pode armazenar em cache um par de sensor/temperatura e gravar em um banco para armazenamento de longo prazo apenas quando ocorrer uma mudança.

Em suma, existem muitas formas de se otimizar tendo em vista capacidade de armazenamento ou bandwidth. Acredito que dois aspectos principais a serem lembrados são como a otimização afeta a capacidade relativa do seu sistema e para o que você está otimizando.

### Esteja preparado(a) para operar

Muito do trabalho verdadeiramente desafiador para o capacity planning, em minha opinião, está em operar capacidade. **Às vezes, as suposições que baseamos no capacity planning no estágio de design não são verdadeiras na prática**. Por isso, estar preparado(a) para operar e, portanto, planejar continuamente é extremamente importante.

**Uma boa prática para detectar equívocos é escrever algumas das suposições feitas na fase de design na forma de alertas**. Digamos que no estágio de design você presuma que o sistema terá 20% de cache hits e, na prática, você tem 5%. Mesmo que você provavelmente tenha monitoramento em vigor, a suposição feita pode escapar. Monitorar as suposições feitas anteriormente permite que você atue de forma proativa ao invés de apenas saber quando chegar a sua próxima conta de infraestrutura ou quando ocorrer um incidente.

Mesmo que você tenha maneiras de confiar nos dados para prever e saber como a carga evolui, você não pode prever todos os cenários. Para reduzir esse risco, o que você pode fazer continuamente é **usar alguns conceitos de [modelagem de threats](https://en.wikipedia.org/wiki/Threat_model) para entender quais proteções estão faltando**, o que acontece se uma certa característica muda, ou se um requisito não funcional muda. Isso ajuda a indicar onde você pode ter pontos cegos.

___

Com isso dito, o capacity planning é um assunto profundo e fascinante. Pode informar as decisões de design, operações de sistemas de suporte e até mesmo ajudá-lo(a) a desafiar os requisitos iniciais. Ter isso como parte do processo de design pode ajudar a aumentar a consciência dos trade-offs que você faz e coloca você em uma posição mais forte para abordar mudanças.


O planejamento da capacidade é frequentemente um assunto pouco enfatisado no design do sistemas. Abordá-lo como parte do processo de design pode ser extremamente útil. Cubro um ponto de partida aqui.

System Design: O básico de Capacity Planning


Se eu tivesse que escolher apenas um método de entrevista para avaliar pessoas engenheiras, provavelmente seria system design. Não porque entrevistas de coding, comportamental, simulação de papeis ou estudo de caso sejam menos valiosas - eles são reveladores e ajudam a construir uma imagem mais complexa do(a) candidato(a). Se você tiver recursos para criar um processo que ofereça suporte à diversidade, uma estrutura justa para evitar bias e o tempo, as pessoas e o treinamento para executar um processo de vários estágios, provavelmente reduzirá a propensão de falsos positivos. No entanto, se eu fosse obrigado a escolher apenas um, escolheria system design.

Acho a mistura entre os critérios subjetivos e objetivos que a entrevista de design impõe muito útil para avaliar os candidatos de vários ângulos. Há uma estrutura razoavelmente bem definida para a avaliação técnica, mas apenas chegar a um bom design não é necessariamente suficiente. Da mesma forma, o comportamento do candidato tem um papel vital a ser avaliado, mas a falta de nexo causal e habilidade técnica revelará claramente a adequação à posição ou não.

Existem muitos recursos por aí que são uma base excelente para as partes mais objetivas. Fiz a curadoria de alguns dos meus favoritos no [apêndice](#appendix) deste artigo. Eles merecem um grande foco na hora de estudar para uma entrevista, pois são a parte mais fundamental da avaliação que está sendo feita. Tendo passado por algumas entrevistas recentemente e praticado, pensei em escrever sobre alguns pontos que aprendi e que acredito que podem ajudar nos aspectos subjetivos, especialmente sobre postura.


### Não se limite a comunicar: colabore com os entrevistadores

Uma das coisas que considero muito úteis nas entrevistas técnicas é transformá-las em colaboração, em vez de apenas uma avaliação. O papel que os entrevistadores devem desempenhar fundamentalmente é avaliar se um candidato é adequado para ser seu colega. Eu acredito que quando você atinge uma atmosfera colaborativa ao entrevistar, você está dando às pessoas uma perspectiva muito melhor para avaliar sua adequação de forma justa.

Com isso em mente, uma vez que o entrevistador compartilha qual é o problema a ser resolvido, uma técnica que pode ajudar é **reformular o objetivo com suas próprias palavras.** Acho que isso ajuda a evitar situações em que você presume entender o que está sendo perguntado. É muito melhor esclarecer com o entrevistador do que desenhar a solução certa para o problema errado. Faça perguntas, por mais óbvias que possam parecer, e tente reunir todas as informações que puder antes de prosseguir.

Com o objetivo melhor definido, é essencial **estabelecer o que está dentro do escopo e o que está fora.** Estreitar quais são os limites do escopo para o problema da entrevista ajudará você a se concentrar no que é mais importante para o design em questão. Fazer concessões no escopo no início impedirá que você gaste o pouco tempo de que dispõe para falar sobre adjacências do problema.

Quando inferirir informações a partir do que lhe foi dito ou quando chegar a uma conclusão, **expresse suas suposições e conclusões.** Você precisa trazer seus entrevistadores para ver o problema do ângulo que você está olhando para fazer um julgamento justo se você está saindo do planejado e te colocar no trilho novamente, se necessário.

Então, ao trabalhar na solução proposta, **evite transformar a experiência em um monólogo. Deixe espaços para feedback**. Entrevistadores geralmente não se importam de sinalizar quando você sair do caminho esperado. Faça com que eles contribuam para a discussão, mesmo que de forma não verbal, independentemente se for sobre as implicações das decisões de design que você está escolhendo e por que, ou de forma mais específica, como se você deve dividir um componente em dois.

Em suma, comunicação é muito importante para as entrevistas técnicas. Além disso, buscar ativamente a colaboração aumenta suas chances de um bom desempenho na entrevista e também ajuda os entrevistadores a avaliar se gostariam de trabalhar com você - e vice-versa.

### Amplo primeiro e fundo depois

É fácil se aprofundar prematuramente nos detalhes do sistema, pois as perguntas da entrevista de design geralmente não cabem no intervalo de tempo disponível, ao contrário de uma entrevista de coding, por exemplo, onde o problema provavelmente se encaixa no tempo disponível. Ninguém espera que você encontre a solução perfeita para um sistema que é operado por dezenas, centenas ou mesmo milhares de pessoas - embora o ideal seja você ter um esboço para resolver o problema de ponta a ponta ao fim da entrevista.

Como nos sistemas da vida real, o design irá evoluir. Feito geralmente é melhor do que perfeito. **Comece simples antes de se tornar complexo, favorecendo a extensibilidade em vez da perfeição**. Apresente o design mais simples que não apresentará problemas óbvios de escalabilidade primeiro, mantenha quem está te entrevistando informado(a) sobre sua estratégia e, quando você cobrir os requisitos propostos, entre em otimizações mais profundas.

Uma maneira que descobri de enquadrar o problema no nível certo como ponto de partida é **colocar-se no lugar do usuário do sistema que você está prestes a projetar.** Basicamente, converse com o entrevistador sobre as etapas que o usuário levaria para usar o produto/sistema que você está projetando para as funcionalidades presentes no escopo. Estar atento às necessidades do usuário ajudará a esclarecer as características deste sistema, por exemplo, o que precisará de APIs públicas à internet, quais componentes terão mais leituras do que escritas, ou quando favorecer consistência em relação à disponibilidade. Olhar para o sistema através da perspectiva de experiência do usuário geralmente sugere o que é fundamental para aquele sistema e ajudará a definir alguns porquês mais adiante.

Quando você sentir que entendeu o todo, criou um design em alto nível e mostrou ao entrevistador que você tem controle sobre o problema no geral, escolha a parte com a qual se sente mais confortável para ir fundo e explore-a. **Foque suas forças ao invés das suas áreas para desenvolvimento.** Provavelmente, o problema em questão tem alguns desafios de escala interessantes para qualquer disciplina. Escolha o seu aspecto favorito do problema sobre o qual você possa falar profundamente, por exemplo otimização de bandwidth no lado do cliente, modelo de dados e particionamento, automação de infra de machine learning ou o que você quiser.

Dito isso, resista ao impulso de entrar em detalhes antes de entender totalmente o problema. Elevar a conversa às motivações e aos resultados esperados primeiro te ajudará a tomar decisões de design mais assertivas e a tornar alguns porquês mais evidentes para você e para a pessoa que te entrevista posteriormente.

### Fale sobre nuances e edge-cases

O que acontecerá se o seu sistema parar de enviar dados para um componente downstream do seu sistema? Como você notifica os sistemas upstream para reverter algo que foi alterado por engano? Como o sistema funciona para o 99º percentil de seus power users? Todas essas são questões que podem influenciar suas escolhas de design, portanto, pensar no que pode dar errado lhe dá a oportunidade de alterá-lo ou de confirmar que tomou as decisões corretas de design.

Especialmente em sistemas distribuídos de grande escala, você geralmente terá que otimizar para características específicas. Isso introduz inexoravelmente comportamentos indesejados - dos quais você precisa estar ciente para tomar a decisão certa. **Fale sobre as compensações que você fez e por que** escolheu uma abordagem ao invés de todas as outras opções que você tinha.

Além disso, **explorar cenários de falha e opções de recuperação** mostrará que você entende o design que você se comprometeu. Isso pode se tornar especialmente interessante quando você pode cobrir não apenas as falhas de sistema, mas como os usuários podem abusar o sistema, quais riscos são introduzidos que você terá que aceitar, ou até mesmo erro humano. Quando possível, fale sobre como você recupera ou evita que isso aconteça.

**Converse sobre como consertar as coisas quando as coisas dão errado**. Um exemplo disso é uma experiência pessoal em que superestimei capacidade em uma entrevista. Ao invés de alocar 1GB de armazenamento para contas gratuitas do sistema que estava desenhando, dediquei 1TB. Percebi que algo estava errado à medida que o armazenamento e bandwidth começaram a parecer absurdos para o problema em questão com o volume de acessos que o entrevistador e eu havíamos combinado. Depois de reconhecer que algo estava errado, falei sobre as etapas que tomaria para reverter o erro se isso fosse ao ar, como manter os usuários que se inscreveram na proposta de 1TB com os benefícios pelos quais pagaram indefinidamente, conversar com equipes responsáveis por publicidade/marketing e growth sobre o erro, e outras medidas de controle de danos que poderiam ser tomadas. Acho que essa conversa acabou sendo ainda mais interessante do que se eu tivesse calculado a capacidade certa a princípio.

Resumindo, as coisas darão errado em algum ponto - mostrar prontidão para trilhar o caminho não tão feliz aumentará sua confiança nas suas escolhas de design, e se você tomou uma decisão errada, ainda tem tempo para se adaptar e torná-la melhor ou pelo menos reconhecer o erro.


### Fale brevemente sobre adjacências do problema

Novamente, dado que a entrevista de design é extremamente limitada em tempo, você precisa estar ciente do que deseja enfatizar. Embora seja ótimo ter um escopo estreito para trabalhar, tocar levemente em tópicos adjacentes ao design em si pode mostrar ainda mais amplitude de conhecimento. Aqui estão alguns exemplos de assuntos a serem cobertos, que podem estar fora do escopo, mas podem aumentar o número de sinais, aumentando assim suas chances de um bom desempenho.

Acredito que a maioria dos engenheiros aprecia o fato de operar sistemas de grande escala é muito difícil. Eu pessoalmente gosto de **cobrir a operações, não apenas o design**. Especialmente em grandes empresas, onde você geralmente tem funções dedicadas de infrastructure engineering, é fácil de achar que ops "vem de graça". Falar brevemente sobre assuntos como alerts, monitoramento, tracing e observabilidade pode revelar problemas ao escalar um design específico.

Especialmente para ambientes altamente regulamentados, como pagamentos e prevenção de abuso, tocar em **segurança, compliance e restrições regulatórias** pode ser uma vantagem. Algumas idéias de assuntos a abordar são retenção de dados ou anonimização de dados para sistemas com informações de identificação pessoal, ou gerenciamento de risco por meio da divisão de componentes em redes internas diferentes para separar escopo de auditorias.

Talvez um aspecto mais relacionado a liderança técnica ou gerenciamento, as decisões de design irão ditar inerentemente como as equipes serão mobilizadas para domínios específicos. Uma grande vantagem de microsserviços é tornar a escalabilidade independente - incluindo pessoas e design organizacional. Falar sobre como o design provavelmente afetará **como você mobiliza as pessoas no conjunto de equipes responsáveis ​​pelo design** e mostrar consciência de escalonamento não apenas de infra-estrutura e sistemas, mas também de organizações pode gerar conversas interessantes.

Meus exemplos aqui são altamente influenciados pela minha própria experiência, mas fazer um breve aparte enquanto você cobre algo dentro do escopo da entrevista pode servir como um sinal adicional e aumentar a confiança do entrevistador em você.

___


Para encerrar, é importante notar que todas essas dicas são baseadas em minhas próprias experiências e preferências. Organizações diferentes se concentrarão em coisas diferentes, e seu melhor ponto de partida é entender as expectativas da empresa para a qual você está se candidatando. Acredito que incorporar os tópicos acima destacados à minha postura quando entrevistando me ajudou, e espero que ajude você também.

___


### Apêndice

Abaixo, adicionei um pequeno apêndice para alguns recursos sobre o lado técnico das coisas. Espero que você goste!

- [Grokking the System Design Interview](https://www.educative.io/courses/grokking-the-system-design-interview) feito pelo [Design Gurus](https://designgurus.org) no educative.io;
- [Designing Data-Intensive Applications](https://dataintensive.net/) por Martin Kleppmann;
- [System Design Primer](https://github.com/donnemartin/system-design-primer) por Donne Martin;
- [High Scalability](http://highscalability.com/all-time-favorites/) blog;
- [How the Web Works](https://github.com/vasanthk/how-web-works) por @vasanthk;
- [SuccessInTech](https://www.youtube.com/c/SuccessinTech/videos), canal no YouTube;
- [TechDummies](https://www.youtube.com/c/TechDummiesNarendraL/videos), canal no YouTube;
- [How we've scaled Dropbox](https://www.youtube.com/watch?v=PE4gwstWhmc) video;
- Amazon's [DynamoDB](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) paper;
- Google's [MapReduce](https://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf) paper;
- Google's [Hypertextual Web Search Engines](http://infolab.stanford.edu/~backrub/google.html) paper;
- Google's [GFS/Google File System](https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf) paper;
- Facebook's [Cassandra](https://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf) paper;
- Facebook's [TAO, a social graph data store](https://www.usenix.org/system/files/conference/atc13/atc13-bronson.pdf) paper;


Algumas ideias sobre como melhorar o desempenho nas partes comportamentais e subjetivas do meu tipo de entrevista técnica favorito: system design.

Engenharia de Software

System Design: O básico de Capacity Planning

Postura em entrevistas de system design