System Design Flashcards
Qual a diferença do API Gateway e Load Balancer?
API Gateway
- Atua como porta de entrada para todas requisições dos clientes que acessam os microsserviços.
- Gerenciamento: serviços como autenticação, controle de acesso, rate limiting, cache, monitoramento, transformação de protocolos e agregação de respostas.
- Escode a estrutura interna dos microsserviços dos clientes.
** Load Balancer **
- Seu papel principal é distribuir as requisições entre diversas instâncias de servidores ou serviços, garantindo que nenhum recurso fique sobrecarregado.
- Melhora performance e resiliência do sistema, evitandos pontos únicos de falha.
- Pode atuar na camada 4 TCP ou camada 7 HTTP;
Em que casos usar um API Gateway antes de um Load Balancer?
Como pode atuar com autenticação, autorização, validação de tokens, rate limiting, políticas de segurança, pode filtrar as requisições, enviando requisições limpas para o load balancer.
- Agregar dados de múltiplos microsserviços.
- Ponto de entrada global -> Assim o load balancer pode distribuir para diferentes regiões.
Em que casos utilizar um Load Balancer antes de um API Gateway?
- Para distribuir o tráfego de entrada entre várias instâncias do API Gateway, garantindo alta disponibilidade e escalabilidade.
- Quando se deseja realizar a terminação TLS e aplicar medidas de segurança iniciais antes que o tráfego chegue ao API Gateway.
- Em arquiteturas distribuídas globalmente, onde um LB global direciona o tráfego para API Gateways regionais.
- Para encaminhar diferentes tipos de tráfego (não apenas requisições de API) de forma inteligente com base em regras definidas.
- Para desacoplar o gerenciamento do tráfego (LB) da lógica de negócio e das políticas de API (API Gateway), simplificando a manutenção e a escalabilidade do sistema.
O que fazer quando não puder usar uma fila?
- Banco de Dados como Fila
- Webhooks
- Soluções In-Memory
Porque usamos fila?
- Desacoplamento de componentes.
- Comunicação assíncrona.
- Escalabilidade.
- Buffer.
- Tolerância a falhas.
- Balanceamento de cargas.
Qual a diferença do RabbitMQ, ActiveMQ, Kafka, AWS Kinesis?
RabbitMQ e ActiveMQ: São brokers de mensagens tradicionais, focados em filas e padrões de publicação/assinatura, com forte ênfase na garantia de entrega e flexibilidade no roteamento.
Kafka: É uma plataforma de streaming e log distribuído, ideal para cenários de processamento em massa e análise de dados.
AWS Kinesis: Ideal para aplicações que já operam na AWS e precisam de uma solução pronta para ingestão, processamento e análise de streams de dados com um mínimo de sobrecarga operacional. Um Kafka sem muitas customizações.
Quais são as Ferramentas de Monitoramento e Observabilidade?
Métricas: Prometheus
Dashboard: Grafana
Logs: ELK
Tracing: Jaeger ou Zipkin
Monitoramento: DataDog, NewRelic
O que é o Teorema CAP? Como utilizá-lo?
O Teorema CAP (Consistency, Availability, Partition Tolerance) é um princípio da computação distribuída que afirma que um sistema distribuído não pode garantir simultaneamente os três seguintes atributos:
C (Consistency - Consistência) → Todos os nós sempre veem os mesmos dados ao mesmo tempo.
A (Availability - Disponibilidade) → O sistema responde a todas as requisições, mesmo que alguns nós estejam indisponíveis.
P (Partition Tolerance - Tolerância a Partição) → O sistema continua operando mesmo que haja falhas na comunicação entre os nós da rede.
📌 Regra principal:
➡️ É impossível ter os três simultaneamente! Um sistema pode ter no máximo dois atributos ao mesmo tempo.
1️⃣ CP (Consistência + Partição Tolerância)
✅ Garante consistência absoluta → Todos os nós sempre têm os mesmos dados.
❌ Perde disponibilidade → Se um nó estiver indisponível, pode bloquear operações.
📌 Exemplo: MongoDB, HBase, Zookeeper
Quando usar?
Quando consistência é mais importante que disponibilidade.
Sistemas bancários, controle de estoque, serviços de autenticação.
2️⃣ AP (Disponibilidade + Partição Tolerância)
✅ Garante que o sistema continue funcionando mesmo com falhas na rede.
❌ Os dados podem ficar inconsistentes temporariamente.
📌 Exemplo: Cassandra, DynamoDB, Riak
Quando usar?
Quando a disponibilidade é mais importante que a consistência.
Redes sociais, caches distribuídos, sistemas de recomendação.
3️⃣ CA (Consistência + Disponibilidade) [Raramente usado]
✅ Todos os nós têm os mesmos dados e sempre respondem.
❌ Não tolera falhas de rede → Se houver uma partição na rede, o sistema pode falhar completamente.
📌 Exemplo: Bancos de dados tradicionais como PostgreSQL, MySQL (modo standalone).
Quando usar?
Quando a aplicação roda em uma única máquina ou datacenter confiável.
Aplicações internas sem requisitos de tolerância a falhas.
🛠 Como escolher a arquitetura com base no CAP?
Cenário Prioridade Escolha Exemplos
Banco Digital Consistência forte CP MongoDB, HBase
E-commerce (carrinho de compras, estoque) Consistência CP PostgreSQL, Zookeeper
Redes sociais (Facebook, Twitter, TikTok) Disponibilidade AP Cassandra, DynamoDB
Cache (Redis, Memcached) Disponibilidade AP Redis, Riak
Serviços Internos (Autenticação, pagamentos) Consistência + Disponibilidade (não distribuído) CA MySQL, PostgreSQL
------------------------------------------------------ ------------------------------------------------------ | Banco Digital | Consistência | CP | MongoDB, HBase | ------------------------------------------------------ | E-commerce (estoque, pedidos) | Consistência | CP | PostgreSQL, Zookeeper | ------------------------------------------------------ | Redes sociais (Facebook, Twitter)| Disponibilidade | AP | Cassandra, DynamoDB | ------------------------------------------------------ | Cache (Redis, Memcached) | Disponibilidade | AP | Redis, Riak | ------------------------------------------------------ | Serviços internos (autenticação) | Consistência + Disponibilidade | CA | MySQL, PostgreSQL | ------------------------------------------------------
Quais são os padrões Arquitetura mais modernos?
- Microsserviços
- Arquitetura orientada a eventos (Event-Driven Architecture)
- Serverless (Function as a Service - FaaS)
- Arquitetura baseada em contêineres (Container-Based Architecture)
- Arquitetura de Malha de Serviços (Service Mesh)
- Arquitetura Baseada em Grafos (Graph-Based Architecture)
- Arquitetura de Células (Cell-Based Architecture)
- Arquitetura de Pipeline de Dados (Data Pipeline Architecture)
SOAP vs API Rest
SOAP: XML, padrão rígido e definido, mensagens encapsulas em envelope.Possui suporte nativo para segurança via WS-Security, que oferece recursos como criptografia, assinaturas digitais e autenticação.
API REST: Usa Json, XML, html, texto simples, leve e flexível. Depende de mecanismos de segurança externos, como HTTPS, OAuth, JWT (JSON Web Tokens) e API keys.
Quais são os tipos de sessões?
- Sticky Session
- Token-Based Sessions
- Centralized Session Store
- Stateless Sessions
- Cookie-Based Sessions
- Client-Side Sessions
Como funciona REST API Cache?
Pode ser feita de três formas:
1. HTTP Header -> Setando Cache-Control: max-age=3600(armazenada por 1 hora), no-cache (pode ser armazenada, mas é verificada no servidor) ou no-store(não deve ser armazenada).
2. Cache no Servidor -> Em memória (Redis, Memcached), CDN, Proxy Reverso.
3. Cache no Cliente (Client-Side Caching)
O cliente (navegador ou aplicativo) armazena as respostas da API localmente.
O cache é controlado pelos cabeçalhos HTTP (Cache-Control, ETag, etc.).
Útil para reduzir requisições repetidas ao servidor.
Como funciona o Redis? Quando e como aplicar?
O Redis (Remote Dictionary Server) é um banco de dados em memória de alto desempenho, usado principalmente como cache, armazenamento de sessões, filas de mensagens.
O Redis é um banco de dados key-value (chave-valor) que armazena dados na memória RAM, o que o torna extremamente rápido
- O Redis suporta replicação mestre-escravo para alta disponibilidade e escalabilidade.
- Pub/Sub (Publicação/Assinatura):Funcionalidade de mensagens assíncronas, onde publicadores enviam mensagens e assinantes as recebem.
O Redis é uma ferramenta poderosa para cenários que exigem baixa latência e alta performance, como cache, armazenamento de sessões e filas de mensagens. Com suas estruturas de dados flexíveis e persistência opcional, ele é uma escolha popular para aplicações modernas.
Quando e como escalar um banco de forma horizontal?
- A escalabilidade horizontal é especialmente útil em cenários onde o volume de dados ou o número de requisições cresce além da capacidade de um único servidor
- Crescimento de Dados, Alta Carga de Trabalho, Disponibilidade e Tolerância a Falhas, Desempenho Geográfico, Custos.
Como?
Sharding - Dividir os dados em partes menores (fragmentos ou “shards”) e distribuí-los em vários servidores. (ex.: ID do usuário, região geográfica). MongoDB, Cassandra.
Replicação - Manter cópias idênticas dos dados em múltiplos servidores. O primário lida com as operações de escrita, enquanto as réplicas lidam com as leituras.PostgreSQL, MySQL, MongoDB, Redis
Clusterização- Agrupar vários servidores para trabalhar como um único sistema. Os nós do cluster compartilham a carga de trabalho e os dados.
Bancos de Dados Distribuídos - Bancos de dados projetados para escalar horizontalmente desde o início. Os dados são distribuídos automaticamente entre os nós. Teorema CAP
Qual a diferença entre Reverse Proxy and Forward Proxy?
Um Forward Proxy (proxy de encaminhamento) atua em nome dos clientes. Ele é colocado entre os clientes (usuários ou dispositivos) e a internet. Quando um cliente faz uma requisição, ela passa pelo Forward Proxy, que então encaminha a requisição ao servidor de destino. Proteger ou controlar clientes
- O cliente configura o Forward Proxy (geralmente no navegador ou no sistema operacional).
- Quando o cliente faz uma requisição (ex.: acessar um site), a requisição é enviada ao Forward Proxy.
- O Forward Proxy faz a requisição ao servidor de destino em nome do cliente.
- O servidor de destino responde ao Forward Proxy.
- O Forward Proxy retorna a resposta ao cliente.
Um Reverse Proxy (proxy reverso) atua em nome dos servidores. Ele é colocado entre os clientes e os servidores de backend. Quando um cliente faz uma requisição, ela é recebida pelo Reverse Proxy, que então encaminha a requisição ao servidor de backend apropriado. Proteger ou otimizar servidores.
O cliente faz uma requisição ao servidor (ex.: acessar um site).
- A requisição é recebida pelo Reverse Proxy.
- O Reverse Proxy decide qual servidor de backend deve processar a requisição.
- O servidor de backend processa a requisição e retorna a resposta ao Reverse Proxy.
- O Reverse Proxy retorna a resposta ao cliente.
