I. Princípios Essenciais de Arquitetura
Escala vertical versus horizontal
- Escalabilidade vertical significa atualizar uma única máquina, como adicionar mais CPU, RAM ou armazenamento mais rápido.
- A escalabilidade horizontal significa adicionar mais máquinas e distribuir o trabalho entre elas.
A instalação vertical é mais fácil, mas atinge os limites do hardware e se torna cara.
A arquitetura horizontal é mais complexa porque exige balanceamento de carga, serviços sem estado e armazenamento compartilhado.
Pense da seguinte forma: na vertical, um super-herói fica mais forte; na horizontal, a formação de uma equipe.
Teorema CAP
O Teorema CAP afirma que, na presença de uma partição de rede, um sistema distribuído deve escolher entre Consistência e Disponibilidade . Consistência significa que todos os usuários veem os mesmos dados ao mesmo tempo.
Disponibilidade significa que o sistema sempre responde, mesmo que os dados estejam ligeiramente desatualizados.
Não é possível ter consistência perfeita e disponibilidade perfeita quando sua rede está inoperante, então você decide qual delas sacrificar para o seu caso de uso.
Teorema PACELC
O PACELC amplia o CAP e afirma: se houver uma partição, escolha Disponibilidade ou Consistência; caso contrário, escolha Latência ou Consistência.
Mesmo quando a rede está funcionando bem, ainda existe o dilema entre leituras lentas, porém consistentes, e leituras rápidas, porém eventualmente consistentes. Sistemas que sincronizam entre regiões geralmente sacrificam a latência para manter uma alta consistência.
Isso explica por que alguns bancos de dados são rápidos, mas ligeiramente desatualizados, enquanto outros são mais lentos, mas sempre precisos.
ÁCIDO vs BASE
ACID preza por transações rigorosas e confiáveis: Atomicidade, Consistência, Isolamento e Durabilidade. É adequado para sistemas financeiros, controle de estoque e qualquer área onde erros podem ser muito custosos.
BASE significa “Basicamente Disponível”, “Estado Flexível” e “Consistência Eventual”, sendo utilizado em grandes sistemas distribuídos que precisam permanecer operacionais e responder rapidamente.
Os sistemas BASE podem apresentar inconsistências temporárias, mas se corrigem com o tempo.
Na prática, muitas arquiteturas combinam ambos, usando ACID para os fluxos financeiros principais e BASE para coisas como feeds e análises.
Taxa de transferência versus latência
- A taxa de transferência (throughput) é a quantidade de solicitações que seu sistema consegue processar por segundo.
- Latência é o tempo que uma única solicitação leva do início ao fim.
Muitas vezes, é possível aumentar a taxa de transferência realizando mais tarefas em paralelo, mas isso pode aumentar a latência caso as filas se acumulem.
Imagine um restaurante que recebe muitos pedidos simultaneamente, mas faz os clientes esperarem bastante. Um bom projeto de sistema busca o equilíbrio entre esses dois aspectos: capacidade suficiente para lidar com picos de demanda, mas baixa latência para uma experiência de usuário fluida.
Lei de Amdahl
A Lei de Amdahl afirma que o ganho de velocidade resultante da paralelização é limitado pela parte que não pode ser paralelizada.
Se 20% do seu sistema é sempre sequencial, nenhuma quantidade de máquinas adicionais resolverá esse gargalo.
Deixa eu explicar melhor.
Se sua solicitação sempre precisar acessar um único banco de dados mestre, esse mestre limitará seu desempenho. Essa lei nos lembra de buscar gargalos em vez de simplesmente adicionar mais servidores.
Consistência forte versus consistência eventual
- A consistência forte significa que todos os usuários veem os mesmos dados imediatamente após uma gravação.
- A consistência eventual significa que as atualizações são distribuídas ao longo do tempo e os nós podem divergir brevemente.
A consistência forte é mais fácil de analisar, mas geralmente é mais lenta e menos eficaz em situações de falha.
A consistência eventual é ótima para sistemas de grande escala, como cronogramas ou contadores, onde a frescura perfeita não é essencial.
O importante é escolher o modelo que melhor se adapte à experiência de usuário que você precisa.
Arquitetura com estado versus arquitetura sem estado
- Um serviço com estado memoriza o contexto do usuário entre as requisições, geralmente armazenando os dados da sessão localmente.
- Um serviço sem estado trata cada solicitação como nova, dependendo de armazenamentos externos, como caches ou bancos de dados, para qualquer estado.
Serviços sem estado são mais fáceis de escalar horizontalmente porque qualquer instância pode lidar com qualquer solicitação.
Sistemas com estado podem ser mais simples de programar, mas mais difíceis de balancear a carga e de realizar failover.
Nos sistemas de nuvem modernos, tentamos transferir o estado para os bancos de dados e manter os serviços o mais livres de estado possível.
Microsserviços vs. Monolitos
Um monolito é uma aplicação única que contém muitas funcionalidades em uma única unidade implantável.
Os microsserviços dividem as funcionalidades em serviços separados que se comunicam pela rede.
Os microsserviços ajudam as equipes a trabalhar de forma independente e a dimensionar diferentes partes separadamente, mas introduzem complexidade em torno da comunicação, depuração e consistência de dados.
Os monolitos são mais simples para começar e geralmente funcionam bem até uma certa escala. Aqui está a parte complicada.
Muitos sistemas excelentes começam como monolitos e evoluem gradualmente para microsserviços quando os problemas se tornam reais.
Arquitetura sem servidor
A computação sem servidor permite executar pequenas funções na nuvem sem precisar gerenciar servidores diretamente. Você paga somente quando seu código é executado, e a plataforma cuida do escalonamento e da infraestrutura para você.
É ideal para cargas de trabalho orientadas a eventos, como webhooks, tarefas em segundo plano ou APIs leves com picos de tráfego.
A desvantagem é um menor controle sobre tarefas de longa duração, inicializações a frio e, às vezes, um custo mais elevado em volumes muito altos.
Pense em computação sem servidor como “funções como serviço”, perfeita para código de integração e serviços leves.
II. Redes e Comunicação
Balanceamento de carga
O balanceamento de carga distribui o tráfego de entrada entre vários servidores, evitando a sobrecarga de um único servidor. Isso melhora tanto a confiabilidade quanto o desempenho, já que a falha de um único servidor não derruba todo o sistema.
Os balanceadores de carga podem ser dispositivos de hardware ou serviços de software. Eles geralmente oferecem suporte a verificações de integridade para interromper o envio de tráfego para instâncias com problemas.
Do ponto de vista de uma entrevista, elas são o primeiro passo para uma ascensão horizontal na carreira.
Algoritmos de balanceamento de carga
Os algoritmos comuns de balanceamento de carga incluem Round Robin, Menor Número de Conexões e Hash de IP.
- O Round Robin alterna entre os servidores em ordem e é simples de implementar.
- A opção “Menor número de conexões” direciona o tráfego para o servidor com o menor número de conexões ativas, o que é útil quando as solicitações variam em duração.
- O IP Hash utiliza um hash do endereço IP do cliente, de forma que o mesmo usuário geralmente se conecta ao mesmo servidor, o que facilita a manutenção da sessão.
A escolha do algoritmo correto afeta a imparcialidade, o uso de recursos e a experiência do usuário.
Proxy reverso vs. proxy direto
- Um proxy reverso fica na frente dos servidores e os representa para os clientes. Ele oculta a topologia interna, pode realizar terminação TLS, cache, compressão e roteamento.
- Um proxy reverso fica à frente dos clientes e os representa para o mundo exterior, geralmente para fins de segurança, armazenamento em cache ou filtragem de conteúdo.
Imagine um proxy reverso como a recepção de uma empresa que esconde todas as salas internas, e um proxy direto como um portal que seu laptop precisa atravessar para acessar a internet.
Entender a diferença ajuda quando se fala de gateways de API e proxies corporativos.
Gateway de API
Um gateway de API é um proxy reverso especial que atua como um ponto de entrada único para todas as chamadas de API em um sistema de microsserviços. Ele gerencia o roteamento para o serviço correto, a limitação de taxa, a autenticação, o registro de logs e, às vezes, a modelagem de respostas.
Isso reduz a complexidade no lado do cliente, já que os clientes se comunicam apenas com um único ponto de extremidade.
Se você sobrecarregar o gateway com muita lógica, ele pode se tornar um gargalo ou um pequeno monolito por si só. Bons projetos o mantêm focado e enxuto.
CDN (Rede de Distribuição de Conteúdo)
Uma CDN é uma rede de servidores geograficamente distribuídos que armazenam em cache conteúdo estático, como imagens, vídeos e scripts, mais perto dos usuários.
Quando um usuário solicita conteúdo, ele é encaminhado para o nó da CDN mais próximo, o que reduz significativamente a latência. Isso também alivia o tráfego dos seus servidores de origem, melhorando a escalabilidade e a resiliência.
As CDNs são essenciais para aplicações globais e para o desempenho da interface.
Considere-os como “cópias locais” dos arquivos pesados do seu site, espalhados pelo mundo.
DNS (Sistema de Nomes de Domínio)
O DNS mapeia nomes de domínio legíveis para humanos em endereços IP.
Ao digitar o nome de um site, seu dispositivo consulta o DNS para encontrar o endereço numérico do servidor.
Possui múltiplas camadas de cache, portanto as respostas são rápidas após a primeira consulta. Também pode ser usado para realizar balanceamento de carga simples, retornando IPs diferentes para o mesmo nome.
Compreender o DNS ajuda a entender por que as alterações de nomes demoram a se propagar e por que algumas interrupções são causadas por configurações incorretas de DNS.
TCP vs UDP
- O TCP é um protocolo confiável e orientado a conexão. Ele garante a entrega ordenada e com verificação de erros por meio de confirmações e novas tentativas.
- O UDP não requer conexão e não garante a entrega ou a ordem dos dados, o que o torna muito mais rápido e leve.
O TCP é adequado para APIs, páginas web e transferências de arquivos, onde a precisão é fundamental.
O UDP funciona bem para aplicações em tempo real, como videochamadas ou jogos, onde a perda ocasional de pacotes é aceitável.
Pense no TCP como uma carta registrada e no UDP como cartões postais rápidos.
HTTP/2 e HTTP/3 (QUIC)
- O HTTP/2 introduziu a multiplexação, que permite que várias requisições compartilhem uma única conexão TCP, reduzindo a sobrecarga. Ele também trouxe recursos como compressão de cabeçalho e push do servidor.
- O HTTP/3 funciona sobre o QUIC, que é baseado no UDP e melhora o tempo de estabelecimento da conexão e o desempenho em redes instáveis. Essas versões visam principalmente reduzir a latência e aproveitar melhor as condições de rede modernas.
Para você, como engenheiro, a ideia principal é: menos configurações de conexão e melhor aproveitamento de uma única conexão.
gRPC vs REST
- REST normalmente usa HTTP com JSON e se concentra em recursos como
/usersURLs ou URLs/orders. É simples, legível para humanos e amplamente utilizado para APIs públicas. - O gRPC utiliza HTTP/2 e mensagens codificadas em binário (protobuf), que são menores e mais rápidas na transmissão pela rede. Ele também suporta streaming bidirecional e tipagem forte.
Em microsserviços, o gRPC é frequentemente preferido para chamadas de serviço para serviço, enquanto o REST é comum para clientes externos.
Use REST quando a legibilidade e a compatibilidade forem importantes, e gRPC quando o desempenho e os contratos forem importantes.
WebSocket e Eventos Enviados pelo Servidor (SSE)
Os WebSockets criam uma conexão full-duplex, onde o cliente e o servidor podem enviar mensagens um para o outro a qualquer momento.
O SSE permite que o servidor envie eventos para o cliente por meio de um canal unidirecional usando HTTP.
WebSockets são ótimos para bate-papos, jogos multiplayer e colaboração ao vivo.
O SSE é mais simples e adequado para casos como atualizações de placar ao vivo ou notificações, onde apenas o servidor precisa enviar as atualizações.
Ambos resolvem problemas de comunicação em tempo real que o HTTP puro não consegue lidar bem.
Votação de longo prazo
O long polling é uma técnica em que o cliente envia uma solicitação e o servidor a mantém aberta até que haja novos dados ou um tempo limite seja atingido.
Quando a resposta é recebida, o cliente abre imediatamente outra solicitação. Isso simula atualizações em tempo real via HTTP puro, sem protocolos especiais.
É menos eficiente que o WebSocket, mas mais fácil de implementar e funciona através da maioria dos proxies e firewalls.
Pense nisso como perguntar “alguma novidade?” e esperar em silêncio até que haja uma resposta.
Protocolo de Fofoca
Um protocolo de fofoca permite que os nós em um sistema distribuído compartilhem informações conversando periodicamente com outros nós aleatórios.
Com o tempo, a informação se espalha como fofoca em um grupo social até que todos tenham uma visão semelhante. Ela é usada para compartilhar informações sobre membros, estado de saúde ou configurações de forma tolerante a falhas.
O protocolo é eventualmente consistente e não depende de uma autoridade central. Isso o torna ideal para grandes clusters onde os nós entram e saem com frequência.
III. Componentes internos do banco de dados e do armazenamento
Fragmentação (Particionamento de Dados)
O particionamento (sharding) divide os dados entre várias máquinas, cada uma contendo um subconjunto dos dados. As estratégias comuns incluem particionamento baseado em intervalo, particionamento baseado em hash e particionamento baseado em diretório.
O principal objetivo é escalar o armazenamento e a taxa de transferência, evitando um único nó de banco de dados gigante.
A parte complicada é escolher uma chave de fragmentação que evite pontos de acesso intenso, onde um fragmento concentra a maior parte do tráfego. Depois de fragmentar o sistema, mover dados entre fragmentos (refragmentação) torna-se um desafio operacional importante.
Padrões de replicação (mestre-escravo, mestre-mestre)
Replicação significa manter múltiplas cópias de dados em nós diferentes.
- Em um modelo mestre-escravo (ou réplica primária), um nó lida com as escritas e replica as alterações para os outros nós que realizam as leituras.
- Em um modelo mestre-mestre (multi-primário), vários nós aceitam gravações e resolvem conflitos.
A replicação melhora o desempenho de leitura e a disponibilidade, mas dificulta a consistência, especialmente quando as gravações são feitas em vários nós.
Em entrevistas, espere que falemos sobre como o atraso na replicação afeta as leituras e como funciona o failover quando um servidor mestre falha.
Hashing consistente
O hash consistente é uma técnica para distribuir chaves entre nós de forma a minimizar a movimentação de dados quando nós são adicionados ou removidos.
As chaves e os nós são colocados em um anel lógico, e cada chave pertence ao nó seguinte no anel.
Quando um nó entra ou sai, apenas uma pequena parte das chaves precisa ser movida. Essa propriedade é muito útil em caches e bancos de dados distribuídos.
Imagine um mapeamento suave que não se desorganiza quando o tamanho do cluster muda.
Indexação de banco de dados (árvores B, árvores LSM)
Os índices aceleram as consultas ao organizar os dados de forma a permitir uma pesquisa rápida.
Árvores B são árvores balanceadas que mantêm os dados ordenados e permitem encontrar intervalos de forma eficiente, sendo comuns em bancos de dados relacionais.
As árvores LSM processam gravações em lote na memória e periodicamente as transferem para o disco, o que torna as gravações muito rápidas, mas as leituras mais complexas.
A questão é a compensação entre cargas de trabalho com muita escrita e cargas de trabalho com muita leitura.
A ideia principal é que os índices são uma estrutura separada que precisa ser atualizada a cada gravação, e é por isso que muitos índices prejudicam o desempenho de inserção.
Registro antecipado de escrita (WAL)
O Write Ahead Logging registra as alterações em um log antes de aplicá-las ao banco de dados principal.
Se ocorrer uma falha no meio de uma transação, o sistema pode reproduzir o log para restaurar um estado consistente. O WAL garante a durabilidade e a atomicidade das transações. Ele também permite técnicas como a replicação a partir do fluxo de logs. Deixe-me explicar por que isso é importante.
Sem o WAL, uma falha no sistema pode deixar seus dados corrompidos ou parcialmente desatualizados.
Normalização vs Desnormalização
- A normalização organiza os dados em tabelas que reduzem a redundância e as dependências, seguindo regras como a primeira forma normal, a segunda forma normal e assim por diante. Isso evita anomalias em atualizações e inserções.
- A desnormalização duplica intencionalmente os dados para acelerar as leituras e reduzir as junções. Em sistemas de grande escala, a desnormalização é comum em caminhos com grande volume de leituras, como armazenar nomes de usuários junto com as postagens em vez de realizar junções a cada vez.
A verdadeira habilidade reside em saber onde se pode desnormalizar com segurança sem quebrar a consistência.
Persistência Poliglota
Persistência poliglota significa usar vários tipos de bancos de dados dentro do mesmo sistema, cada um escolhido por sua principal função. Você pode usar um banco de dados relacional para transações, um banco de dados de documentos para registros, um banco de dados chave-valor para cache e um banco de dados de grafos para relacionamentos.
Em vez de forçar tudo em um único banco de dados, você escolhe a ferramenta certa para cada tarefa.
A contrapartida é uma maior complexidade operacional e maior necessidade de conhecimento por parte da equipe.
Filtros de brilho
Um filtro de Bloom é uma estrutura de dados que utiliza pouco espaço e responde rapidamente à pergunta “este item pode estar no conjunto?”, com possíveis falsos positivos, mas sem falsos negativos. Ele usa múltiplas funções de hash para definir bits em um vetor de bits quando itens são inseridos.
Para verificar a presença do item, você testa os mesmos bits; se algum bit for zero, o item definitivamente não está presente.
Bancos de dados e caches usam filtros de Bloom para evitar buscas desnecessárias em disco ou falhas de cache.
Pense neles como filtros rápidos que dizem “definitivamente não” ou “talvez”.
Bancos de dados vetoriais
Bancos de dados vetoriais armazenam e consultam vetores, que são representações numéricas de dados como texto, imagens ou áudio. Esses vetores provêm de modelos como embeddings e permitem buscas por similaridade, como “encontrar documentos mais semelhantes a este”.
Em vez de comparações exatas de igualdade, eles usam métricas de distância como similaridade de cosseno ou distância euclidiana. Isso é essencial para sistemas modernos de busca, recomendação e assistentes de IA.
Em entrevistas, basta saber que os bancos de dados vetoriais suportam a busca por vizinhos mais próximos em dados de alta dimensionalidade.
IV. Confiabilidade e Tolerância a Falhas
Limitação de taxa
A limitação de taxa controla quantas solicitações um usuário, IP ou chave de API pode fazer em um determinado período. Ela protege seu sistema contra abusos, picos de tráfego acidentais e loops descontrolados.
As estratégias comuns incluem janela fixa, janela deslizante e balde de tokens.
Os limites de taxa geralmente são aplicados no gateway da API ou no balanceador de carga.
Considere-os como freios de segurança que impedem a sobrecarga dos recursos compartilhados.
Padrão de disjuntor
Um disjuntor monitora as chamadas para um serviço remoto e “desativa” o circuito se houver muitas falhas.
Quando aberto, ele rejeita imediatamente novas solicitações em vez de tentar novamente o serviço com problemas.
Após um período de resfriamento, o sistema permite algumas chamadas de teste para verificar se o serviço se recuperou e, caso sejam bem-sucedidas, encerra a execução. Esse padrão evita falhas em cascata, nas quais um serviço lento pode derrubar todo o sistema.
Aqui está a parte complicada. Os disjuntores devem ser ajustados com cuidado para que não abram de forma muito brusca ou muito tarde.
Padrão de antepara
O padrão de anteparo isola partes de um sistema, de modo que uma falha em uma área não comprometa todo o sistema. Isso pode significar pools de conexão separados, pools de threads ou até mesmo clusters de serviços inteiros para diferentes funcionalidades.
Se uma das anteparas estiver congestionada com tráfego, as outras continuam funcionando.
O nome vem das anteparas dos navios, que retêm a água em um compartimento específico.
Em discussões de projeto, o uso de anteparas demonstra que você está considerando o isolamento de falhas e o raio de explosão.
Padrões de Repetição e Recuo Exponencial
As novas tentativas ajudam a recuperar de erros transitórios, como timeouts de rede ou sobrecarga temporária.
O recuo exponencial significa que cada nova tentativa espera mais tempo que a anterior, como 1 segundo, 2 segundos, 4 segundos e assim por diante. Isso impede que seu cliente sobrecarregue um serviço que já está com dificuldades.
Boas políticas de repetição também usam jitter (pequena aleatoriedade) para evitar comportamentos de manada em alta velocidade.
Deixa eu explicar melhor.
Tentativas repetidas sem um período de espera podem piorar as interrupções em vez de ajudar.
Idempotência
Uma operação é idempotente se realizá-la várias vezes tiver o mesmo efeito que realizá-la uma única vez.
Por exemplo, “definir o status do usuário como ativo” é idempotente, enquanto “incrementar o saldo da conta em 10” não é.
A idempotência é crucial quando os sistemas utilizam novas tentativas, pois a mesma solicitação pode ser enviada mais de uma vez.
As APIs geralmente exigem chaves de idempotência em operações como pagamentos para evitar cobranças duplicadas.
Em entrevistas, sempre mencione a idempotência quando falar sobre entrega pelo menos uma vez ou tentativas de fecundação.
Batimento cardíaco
Um batimento cardíaco é um sinal periódico enviado por um serviço ou nó para indicar que está ativo e funcionando corretamente.
Sistemas de monitoramento ou coordenadores escutam os batimentos cardíacos.
Se pararem de recebê-los, eles marcam o nó como inativo e acionam ações de failover ou escalonamento.
Os batimentos cardíacos são ferramentas simples, mas poderosas, para detecção de atividade. Pense neles como as “verificações de pulso” do sistema.
Eleição de Líder (Paxos, Balsa)
A eleição de líder é o processo de escolha de um único nó para atuar como coordenador entre vários.
Algoritmos como Paxos e Raft garantem que apenas um líder seja escolhido e que todos os nós eventualmente concordem sobre quem será esse líder.
O líder lida com tarefas como atribuir trabalho, gerenciar metadados ou ordenar gravações. Se o líder falhar, um novo é eleito automaticamente.
Você não precisa memorizar os cálculos matemáticos para entrevistas, mas deve saber que os algoritmos de consenso são a base de muitos sistemas críticos, como repositórios de metadados e logs distribuídos.
Transações Distribuídas (Padrão SAGA)
Uma transação distribuída abrange vários serviços ou bancos de dados.
O padrão SAGA modela essa transação como uma sequência de etapas locais com ações compensatórias para reversões.
Em vez de bloquear tudo como em uma única transação ACID, cada serviço executa sua parte e publica um evento. Se algo falhar, etapas compensatórias tentam desfazer as alterações anteriores. Isso se encaixa naturalmente com microsserviços e consistência eventual.
A contrapartida é uma lógica mais complexa e a possibilidade de falhas parciais que devem ser tratadas com elegância.
Compromisso de duas fases (2PC)
O Two Phase Commit é um protocolo que tenta fornecer transações atômicas em vários nós.
- Na primeira fase, o coordenador pergunta a todos os participantes se eles podem se comprometer.
- Na segunda fase, se todos concordarem, o sistema os instrui a confirmar a decisão; caso contrário, instrui-os a reverter a decisão.
O protocolo 2PC oferece fortes garantias, mas pode bloquear se o coordenador falhar, e é caro em grande escala devido ao bloqueio.
Em sistemas de nuvem modernos, o protocolo 2PC é frequentemente evitado em caminhos de alta taxa de transferência e substituído por padrões como o SAGA.
V. Armazenamento em cache e mensagens
Armazenamento em cache
O armazenamento em cache guarda os dados acessados com frequência em uma camada de armazenamento rápida, geralmente na memória, para reduzir a latência e a carga do servidor.
As camadas de cache comuns incluem caches internos ao processo, armazenamentos externos de chave-valor e CDNs. O armazenamento em cache é especialmente eficaz para cargas de trabalho com grande volume de leitura e cálculos dispendiosos.
E aqui está a parte complicada. Dados desatualizados e invalidados tornam o armazenamento em cache mais difícil do que parece à primeira vista.
Como diz o ditado, a invalidação de cache é um dos problemas mais difíceis da ciência da computação.
Estratégias de cache (cache à parte, write-through, etc.)
- O termo “cache aside” significa que o aplicativo lê do cache e, em caso de falha, carrega os dados do banco de dados e grava no cache.
- O recurso Write-through realiza gravações simultâneas no cache e no banco de dados, garantindo que o cache e a origem estejam sempre sincronizados.
- A operação de “write back” primeiro grava no cache e depois descarrega os dados para o banco de dados, o que é rápido, mas arriscado caso o cache falhe.
Cada estratégia equilibra, de forma diferente, inovação, complexidade e desempenho.
Os entrevistadores adoram quando você menciona qual estratégia escolheria para um determinado cenário.
Políticas de remoção de cache (LRU, LFU)
As políticas de remoção de cache decidem quais itens remover quando o cache estiver cheio.
- O LRU (Least Recently Used – Menos Recentemente Usado) remove itens que não foram acessados recentemente, partindo do pressuposto de que itens acessados recentemente têm maior probabilidade de serem usados novamente.
- LFU (Least Frequently Used – Menos Frequentemente Usado) remove itens que são acessados raramente, priorizando a popularidade a longo prazo.
Alguns sistemas utilizam algoritmos aleatórios, FIFO ou avançados.
A ideia principal é que o espaço em cache é limitado, então você quer manter os itens mais valiosos na memória.
Filas de mensagens (ponto a ponto)
Uma fila de mensagens permite que um componente envie mensagens para outro sem que ambos precisem estar online ao mesmo tempo.
Em um modelo ponto a ponto, as mensagens em uma fila são consumidas por um receptor e, em seguida, removidas. Isso desacopla o remetente e o receptor, permitindo que eles escalem e lidem com falhas de forma independente.
As filas são ótimas para tarefas em segundo plano, envio de e-mails e processamento assíncrono de tarefas pesadas.
Considere-as como uma lista de tarefas compartilhada entre os serviços.
Pub Sub (Publicar e Assinar)
Em um modelo de publicação/ assinatura (pub/sub) , os editores enviam mensagens para tópicos, não diretamente para os consumidores.
Os assinantes ouvem tópicos de seu interesse e recebem cópias de mensagens relevantes. Isso possibilita uma comunicação no estilo de transmissão e uma relação flexível entre produtores e consumidores.
Vários serviços podem reagir ao mesmo evento de maneiras diferentes, como registro de logs, análises e notificações.
Em entrevistas, o conceito de pub/sub aparece frequentemente em projetos orientados a eventos, como feeds de atividades ou event sourcing.
Filas de cartas não entregues
Uma fila de mensagens não processadas armazena mensagens que não puderam ser processadas com sucesso após várias tentativas.
Em vez de ficar tentando indefinidamente e bloqueando a fila principal, essas mensagens são movidas para outro lado.
Os engenheiros podem inspecionar a fila de mensagens não entregues para depurar problemas, corrigir dados ou reproduzir mensagens posteriormente. Esse padrão melhora a resiliência e impede que seu sistema fique preso em “mensagens problemáticas”.
Considere isso como uma área de espera para trabalhos problemáticos.
VI. Observabilidade e Segurança
Rastreamento Distribuído
O rastreamento distribuído acompanha uma única solicitação à medida que ela flui por vários serviços. Cada serviço adiciona um ID de rastreamento e informações de intervalo para que você possa reconstruir o caminho completo de uma solicitação. Isso é extremamente útil ao depurar respostas lentas ou falhas em arquiteturas de microsserviços.
Sem rastreamento, você vê apenas erros isolados. Com ele, você vê o contexto completo, abrangendo serviços, filas e bancos de dados.
SLA vs SLO vs SLI
Um SLA (Acordo de Nível de Serviço) é uma promessa externa feita aos clientes, como por exemplo, “99,9% de tempo de atividade por mês”.
Um SLO (Objetivo de Nível de Serviço) é uma meta interna que os engenheiros buscam atingir, geralmente mais rigorosa que o SLA. Um SLI (Indicador de Nível de Serviço) é a métrica efetivamente medida, como tempo de atividade real ou taxas de sucesso de solicitações.
Considere o SLA como o contrato, o SLO como a meta e o SLI como o placar.
Em entrevistas, o uso correto desses termos demonstra maturidade no pensamento sobre confiabilidade.
OAuth 2.0 e OIDC
OAuth 2.0 é uma estrutura para autorização delegada. Ela permite que os usuários concedam a um aplicativo acesso limitado aos seus recursos sem compartilhar senhas.
O OIDC (OpenID Connect) se baseia no OAuth 2.0 para adicionar autenticação, permitindo que os clientes verifiquem quem é o usuário e obtenham informações de identidade do usuário. Essa é a base de muitos fluxos de “Login com X”.
A ideia principal é que um servidor de autorização emita tokens nos quais clientes e APIs possam confiar.
Aperto de mãos TLS/SSL
TLS/SSL protege a comunicação entre o cliente e o servidor, criptografando os dados em trânsito.
Durante o handshake , o cliente e o servidor concordam com os algoritmos de criptografia, trocam chaves de forma segura e verificam os certificados.
Assim que a autenticação for concluída, todos os dados subsequentes serão criptografados e protegidos contra interceptação. É isso que faz com que o pequeno ícone de cadeado apareça no seu navegador.
Sem o TLS, qualquer pessoa na rede poderia ler ou modificar o tráfego sensível.
Segurança de Confiança Zero
Zero Trust é um modelo de segurança que prega: “Nunca confie, sempre verifique”. Ele parte do princípio de que as ameaças podem existir tanto fora quanto dentro da rede.
Toda solicitação deve ser autenticada, autorizada e criptografada, mesmo que venha de dentro do seu data center ou VPC. O acesso é concedido com base na identidade, postura do dispositivo e contexto, e não apenas por estar “dentro do firewall”.
Nas arquiteturas modernas, o conceito de Zero Trust está se tornando a abordagem padrão para o projeto de sistemas seguros.
Referência
- Roteiro completo para aprender design de sistemas (gratuito)
- Entendendo a Entrevista de Design de Sistemas
- Curso Intensivo de Design de Sistemas (Gratuito)
Principais conclusões
- O projeto de sistemas consiste principalmente em compreender as compensações envolvidas: consistência versus disponibilidade, latência versus taxa de transferência, simplicidade versus flexibilidade.
- Escalar não é simplesmente “adicionar mais servidores”. É preciso pensar em balanceamento de carga, fragmentação, replicação e gargalos.
- Padrões de confiabilidade como limitação de taxa, disjuntores, novas tentativas e anteparos existem porque falhas são normais em sistemas distribuídos.
- O armazenamento em cache, as filas e o modelo de publicação/assinatura são seus melhores aliados em termos de desempenho e desacoplamento, mas introduzem novos desafios relacionados à consistência e à ordenação.
- Conceitos de observabilidade e segurança, como rastreamento, SLIs, OAuth, TLS e Zero Trust, são essenciais para sistemas que não sejam apenas rápidos, mas também seguros e depuráveis.
Fonte: https://designgurus.substack.com/p/50-system-design-concepts-for-beginners