Além da série sobre algoritmos, também estou começando uma serie sobre System Design. Mesma coisa que comentei antes: eu simplesmente troquei o X/Twitter e Bluesky pelo Dev.to, portanto, é um conteúdo mais descompromissado, algo que eu apenas to tirando da cabeça e regstrando, como fazia com as threads. Os artigos "formais" eu publico aqui toda sexta feira, às 9 da manhã.
Para me acompanhar no conteúdo, será ideal que você já tenha familiaridade pelo menos com a definição do que é System Design (isso você acha fácil na internet, nem tem porque explicar), e com desenvolvimento end-to-end de uma aplicação incluindo front, backend, banco de dados, segurança, infraestrutura. E também com arquitetura. Resumo, vai ser mais fácil se você já foi senior ou estiver em vias de se tornar senior. Eu realmente não acho que já saber System Design deve ser uma preocupação de Junior de mercado ( que não é de Big Tech).
Estou lendo o livro do autor Alex Xu, "Grokking the system design interview" que me pareceu bem completo e num preço que eu podia pagar. Também estou fazendo mapas mentais no Canva como forma de registrar os pontos chave do que estou lendo porque, senão, até a metade do livro, eu já não vou lembrar mais do que vi no inicio.
Já tinha feito algo parecido (resumos de mapas mentais) sobre o que é esperado de uma pessoa que trabalhe como arquiteta de software. Foi um trabalho bem demorado mas ficou tão bom que eu acho que valeu a pena o tempo dedicado e quero fazer o mesmo para outros temas. Se você se interessar, tenho o desenho que eu fiz publicado no Pinterest.
Mas, voltando para o assunto de hoje, que é System Design...
O que eu tenho anotado lendo o primeiro capítulo é o seguinte:
obs: eu adoro fazer essas anotações, mapas mentais...meu lado de artista precisa de coisas visuais
Dando um pouco mais de detalhes, a ideia é levantar estes pontos iniciais antes de começar a fazer um desenho robusto. A ideia é ter essas validações importantes logo no começo. O livro é focado em entrevistas de SD (System Design) então, tudo começa com um passo a passo de por onde começar seu projeto: com perguntas
Requisitos
Embora todo desafio de SD tenha um escopo, esse escopo não trás muitas definições precisas. Então, é bom confirmar o entendimento nesta etapa, com perguntas que busquem entender o quê é o foco do sistema, tipo de dados que passarão por lá, necessidade de atualização em tempo real dos dados e quais seriam as limitações ( o que está fora do escopo) entre outras perguntas pertinentes para entender o que o sistema "é" ou precisa ser.
Design de interface
Essa etapa é o entendimento básico de contratos de API, com quais sistemas a aplicação deve se comunicar e quais os contratos esperados em cada uma dessas pontas. Caso não tenha uma definição expressa, fazer a definição imaginada e validar com quem está aplicando o teste (feedback nessa etapa é primordial)
Estimativa da escala do sistema
Quanto será preciso de armazenamento? O quando esta aplicação pode crescer? Qual velocidade de internet estamos esperando? Essas e outras perguntas devem ser focadas em entender o quanto é esperado de elasticidade e escalabilidade (fazendo um parênteses aqui, estou relendo "Software Architecture — the Hard Parts" e estou justamente na parte que os autores discutem sobre estes dois pontos, bem no começo do livro. Queria dizer que planejo escrever sobre o que estou aprendendo neste, mas, tenho outro livro, "Padrões de Javascript" que estou finalizando a leitura e logo mais quero escrever sobre).
Modelo de dados
É preciso conseguir definir as entidades de dados, mesmo sem uma precisão perfeita mas, entender as interações necessárias e aspectos mais práticos como capacidade de armazenamento, criptografia, disponibilidade dos dados e outros pontos relevantes pensando no que foi definido nos passos anteriores.
5-6 blocos de design alto nível
Depois de levantar todas as informações, a ideia é criar um diagrama de alto nível de 5 a 6 blocos, mais pra validar todo o escopo entendido e já apresentar uma primeira solução. Acho que é um exercício bem interessante essa visão macro, principalmente porque trabalhando no desenvolvimento, podemos nos acostumar apenas na visão aplicação.
2-3 componentes com detalhes
Depois dos feedbacks da primeira parte da solução, a sugestão é focar em 2 ou 3 componentes (as entrevistas de System Design são curtas em relação ao que vai ser construído, então, faz muito sentido focar na parte que importa mais naquele momento, ainda mais porque não existe apenas uma resposta para as perguntas) e se focar em apresentar trade-offs de cada abordagem. Este ponto eu achei bem interessante também, de procurar apresentar mais de uma forma de fazer a mesma coisa e pontuando o que tem as desvantagens mais gerenciáveis.
Identificar possíveis gargalos
Após essa parte do desenho do sistema, vem a parte de identificar se tem algum ponto de falha e quais as possíveis formas de mitiga-lo (se é possível, inclusive). Aqui também entra a parte de monitoria de performance, por exemplo.
Por fim, tem um desafio de criar um sistema encurtador de URL, que eu definitivamente vou tentar fazer com o que já aprendi ate agora antes de olhar no livro como foi feita a solução. No fim das contas, o exercício de System Design é sobre prática.
Independente da questão de estudar para passar em processos seletivos de big techs, no meu trabalho atual, esse conhecimento vai ser incrivelmente util porque, embora eu esteja acostumada a pensar em desenho de sistemas, normalmente eu tenho semanas e até meses para criar esse desenho.
Fazer algo desse tipo em uma hora é definitivamente muito interessante e vai ser util porque conseguirei trabalhar melhor em reuniões de arquitetura e definições com a minha gestão técnica, porque vai ser muito mais proveitoso eu trazer ali na hora as melhores perguntas e um desenho e sair da reunião com uma hipótese cujos pontos principais foram validados com as minhas partes interessadas.
Então, fica meu endosso para o estudo desse tema se você está hoje num cargo que envolve decisões de sistemas e arquiteturas. Se você atua com foco na implantação de soluções, ate aqui eu entendo que focar em algoritmos vai ser mais vantajoso.
No próximo post, vou apresentar minha solução do encurtador de URL :) Tentarei fazer em 45 minutos, vamos ver o que vai sair haha
Top comments (2)
Ótimo conteúdo :D
Algumas perguntas:
Você está lendo três livros no momento? Se sim, como você estrutura a leitura e o fluxo de ideias desenvolvidas? Você acredita que o mapa mental facilita essa transição entre conteúdos (livros) ou, por serem conteúdos que de alguma maneira se conectam, é possível realizar a troca de contexto sem grandes perdas?
Outra pergunta: atualmente estou estudando Java. Já passei por algumas linguagens e frameworks e, para praticar o que venho estudando sobre a linguagem, decidi também criar um encurtador de URL kkkkk (mas demorou mais que 45 minutos). Depois de finalizado, você poderia dar uma olhada e me dar algum feedback? Se possível, claro :D
(talvez eu esteja fugindo um pouco do assunto do artigo, sorry :s )
Oii! Sim, estou lendo 3 e pra mim é tipo ver 3 series diferentes: os assuntos não se parecem, ai eu nem tenho como confundir mas, o que mais me importa são as anotações que eu gero.
E pode mandar seu projeto sim!!! Adoraria oferecer feedback :)