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.
🚀 Casos de Uso do Redis
✔ Cache de dados → Melhora a performance de APIs e aplicações.
✔ Sessões de usuários → Mantém sessões sem precisar armazenar em banco de dados tradicionais.
✔ Filas e mensagens → Alternativa leve para sistemas como RabbitMQ e Kafka.
✔ Rate Limiting → Controla requisições por usuário/IP, evitando abusos.
✔ Ranking e Leaderboards → Jogos e aplicativos com pontuações ordenadas.
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.
O que é um Rate Limiter? Como funciona?
O Rate Limiter funciona monitorando o número de solicitações feitas a um serviço e aplicando restrições conforme regras pré-definidas. Se um usuário ou sistema exceder o limite permitido, ele pode ser temporariamente bloqueado ou ter suas requisições negadas.
Suponha que um sistema permita 100 requisições por minuto por IP. Se um usuário tentar enviar 150 requisições em um minuto, o Rate Limiter pode:
Bloquear requisições adicionais e retornar um HTTP 429 (Too Many Requests).
Colocar o usuário em uma fila de espera.
Aplicar um tempo de bloqueio antes que ele possa fazer novas requisições.
Como funciona o Single Sign On (SSO)?
Single Sign-On (SSO) é um método de autenticação que permite que um usuário acesse vários sistemas ou aplicativos com um único login. Em vez de exigir que o usuário insira credenciais separadas para cada serviço, o SSO centraliza a autenticação em um único provedor de identidade (IdP - Identity Provider).
Como o SSO funciona?
O processo do SSO envolve três atores principais:
- Usuário: A pessoa que deseja acessar um serviço.
- Provedor de Identidade (IdP - Identity Provider): O sistema responsável por autenticar o usuário e emitir tokens ou credenciais de sessão.
- Provedor de Serviço (SP - Service Provider): O sistema ou aplicação que o usuário deseja acessar.
- Fluxo de funcionamento do SSO (exemplo com um sistema web):
- O usuário tenta acessar um serviço (por exemplo, um painel de administração).
- O serviço redireciona o usuário para o IdP para autenticação.
- O usuário insere suas credenciais no IdP (por exemplo, Google, Okta, Microsoft Entra ID).
- Se as credenciais estiverem corretas, o IdP gera um token de autenticação e redireciona o usuário de volta ao serviço original.
- O serviço valida o token e concede acesso ao usuário.
- Para acessos futuros, o usuário não precisa inserir novamente as credenciais, pois a sessão já está autenticada no IdP.
Como que o Kafka funciona? Por que é tão rápido?
Como o Kafka funciona?
O Kafka segue um modelo publicador/assinante (Pub/Sub), onde produtores enviam mensagens para um tópico e consumidores assinam esses tópicos para processar os dados.
Por que o Kafka é tão rápido?
O Kafka é projetado para alta performance e baixa latência. Os principais fatores que o tornam rápido são:
- Armazenamento baseado em Log Append-Only
- Uso de Partições
- Uso eficiente de disco e memória (Zero-Copy Transfer). Como resultado, mensagens podem ser lidas e enviadas quase tão rápido quanto a velocidade do disco e da rede.
- Retenção de mensagens baseada no tempo. (Padrao 7 dias)
- Processamento assíncrono e escalável
Casos de Uso do Kafka
O Kafka é utilizado por grandes empresas como Netflix, Uber, LinkedIn, Twitter e Spotify para:
- Streaming de eventos e logs (monitoramento, métricas de uso).
- Filas de mensagens escaláveis (desacoplamento de microservices).
- Processamento de Big Data (integração com Spark, Flink, Elasticsearch).
- Monitoramento em tempo real (análises financeiras, antifraude).
Qual a diferença entre JWT, OAuth e SAML?
JWT (JSON Web Token) é um formato de token autocontido usado para transmitir informações de forma segura entre partes. Ele é amplamente utilizado em autenticação baseada em tokens e em fluxos de autorização como OAuth 2.0.
OAuth 2.0 é um protocolo de autorização que permite que um usuário conceda a um aplicativo acesso limitado a seus recursos sem compartilhar suas credenciais.
SAML é um protocolo baseado em XML usado principalmente para autenticação federada e Single Sign-On (SSO) em sistemas empresariais.
🔹Use JWT → Para autenticação em APIs RESTful e aplicações Web/Mobile que precisam de tokens autocontidos.
🔹 Use OAuth 2.0 → Quando precisar de autorização delegada, permitindo que usuários concedam permissões a terceiros (ex: login via Google/Facebook).
🔹 Use SAML → Quando precisar de SSO corporativo para sistemas internos (ex: integração com Active Directory, Google Workspace, Salesforce).
Qual a diferença entre API REST e gRPC?
REST (Representational State Transfer) é um estilo arquitetural que usa HTTP como protocolo de comunicação. Ele segue princípios como statelessness (sem estado), recursos identificáveis via URL e operações CRUD (Create, Read, Update, Delete) através de métodos HTTP (GET, POST, PUT, DELETE).
Características do REST
✅ Formato de Dados: Normalmente JSON (pode suportar XML).
✅ Facilidade de Uso: Simples de integrar com qualquer tecnologia.
✅ Baseado em HTTP: Requisições são feitas via URLs e verbos HTTP.
✅ Cacheável: Pode utilizar caching para melhorar a performance.
❌ Desempenho: JSON é verboso e pode ser mais lento que outros formatos binários.
❌ Overhead: Cada requisição precisa incluir headers e metadados HTTP,
gRPC (Google Remote Procedure Call) é um framework de comunicação de alta performance desenvolvido pelo Google. Ele usa HTTP/2 e Protocol Buffers (Protobuf) para serialização de dados, tornando-o mais eficiente que REST.
Características do gRPC
✅ Formato de Dados: Usa Protobuf (binário), que é mais leve e rápido que JSON.
✅ Baseado em HTTP/2: Suporta multiplexing (múltiplas requisições na mesma conexão).
✅ Streaming: Permite comunicação bidirecional (client-server podem enviar dados continuamente).
✅ Eficiência: Requisições são menores e mais rápidas devido ao formato binário.
❌ Complexidade: Requer gRPC stubs gerados a partir de arquivos .proto.
❌ Menos Suporte para Navegadores: REST funciona direto no browser, gRPC precisa de proxies para funcionar bem em chamadas web.
Quando usar REST ou gRPC?
🟢 REST é melhor quando:
Você precisa de uma API pública acessível por navegadores.
Simplicidade e compatibilidade são mais importantes que desempenho.
Deseja expor uma API amigável para desenvolvedores externos.
Sua aplicação não exige alta performance ou comunicação em tempo real.
🟢 gRPC é melhor quando:
Comunicação entre microservices, onde a latência é crítica.
Streaming de dados em tempo real (exemplo: chat, processamento de eventos).
Você precisa de suporte a múltiplas linguagens e quer geração automática de código.
O tráfego precisa ser mais eficiente (exemplo: dispositivos IoT, mobile).
Como funciona um CDN?
Um CDN (Content Delivery Network) é uma rede distribuída de servidores que armazena e entrega conteúdo (como imagens, vídeos, arquivos CSS/JS e até páginas HTML) de forma mais rápida para usuários ao redor do mundo. Ele reduz a latência e melhora a performance de sites e aplicações web.
Quando um usuário acessa um site que usa um CDN, o conteúdo não é carregado diretamente do servidor principal (origin server), mas sim do servidor CDN mais próximo (edge server). Isso reduz o tempo de resposta e melhora a experiência do usuário.
Benefícios de um CDN
✅ Menos latência: O conteúdo é carregado do servidor mais próximo do usuário.
✅ Menos carga no servidor de origem: Como os servidores CDN armazenam o cache dos arquivos, o servidor principal recebe menos requisições.
✅ Maior disponibilidade e redundância: Se um servidor falhar, outro assume automaticamente.
✅ Escalabilidade: Suporta grandes quantidades de tráfego sem sobrecarregar um único servidor.
✅ Segurança: Pode oferecer proteção contra ataques DDoS e bloquear tráfego malicioso.
Exemplos de CDNs populares
Cloudflare
Amazon CloudFront
Akamai
Google Cloud CDN
Microsoft Azure CDN
Fastly
Algoritmos para Load Balancer
1️⃣ Round Robin
2️⃣ Weighted Round Robin (Round Robin Ponderado) - Servidor com pesos
3️⃣ Least Connections (Menos Conexões)
4️⃣ Least Response Time (Menor Tempo de Resposta)
5️⃣ IP Hash (Hash de IP) -> Sessões persistentes
6️⃣ Consistent Hashing (Hashing Consistente)
7️⃣ Random (Aleatório)
8️⃣ Adaptive Load Balancing
Stateful Architecture vs Stateless Architecture
Stateful o server lembra quem você é
Staless os servidores se lembram de você por meio de um banco compartilhado, cache ou de sessão por cookie no cliente.
O que significa o acrônimo ACID no contexto de bancos de dados?
ACID significa:
- Atomicidade
- Consistência
- Isolamento
- Durabilidade
São propriedades que garantem a confiabilidade das transações em um banco de dados.
O que é Atomicidade (Atomicity) e por que é importante?
Atomicidade garante que uma transação seja tratada como uma única unidade indivisível:
- Todas as operações são executadas com sucesso OU
- Nenhuma delas é executada
Se qualquer parte da transação falhar, toda a transação é revertida (rollback).
Dê um exemplo prático de Atomicidade
Cenário: Transferência bancária entre duas contas
- Sistema debita R$100 da conta A
- Sistema falha antes de creditar na conta B
- Atomicidade em ação: O débito é automaticamente revertido
- Resultado: O dinheiro não ‘desaparece’
Ou a transferência completa acontece, ou nenhuma mudança é feita.
O que é Consistência (Consistency) em transações de banco de dados?
Consistência assegura que:
- Uma transação leva o banco de dados de um estado válido para outro estado válido
- Todas as regras de integridade são mantidas
- Os dados devem satisfazer todas as restrições definidas após a transação
É como um guardião das regras do banco de dados.
Dê um exemplo prático de Consistência
Dê um exemplo prático de Consistência
Cenário: Sistema bancário com regra de saldo mínimo R$0
- Saldo atual: R$80
- Cliente tenta sacar R$100
- Consistência em ação: Transação é rejeitada
- Motivo: Violaria a regra de saldo não-negativo
A consistência protege as regras de negócio.
Como funciona o Isolamento (Isolation) em transações?
Isolamento garante que:
- Transações concorrentes são executadas de forma isolada
- Parecem ser sequenciais para o sistema
- Uma transação não vê dados intermediários de outra
- Evita problemas de concorrência
Como se cada transação estivesse sozinha no banco.
Dê um exemplo prático de Isolamento
Cenário: E-commerce com último produto em estoque
- Cliente A e B tentam comprar simultaneamente
-
Isolamento em ação:
- Cliente A inicia compra
- Cliente B não vê produto como vendido ainda
- Cliente A finaliza compra
- Cliente B recebe ‘produto esgotado’
Evita vendas duplicadas e mantém consistência.
O que significa Durabilidade (Durability) em ACID?
Durabilidade garante que:
- Transações confirmadas (commit) são permanentes
- Dados sobrevivem a:
- Quedas do sistema
- Falhas de energia
- Erros de hardware
Uma vez confirmado, está salvo para sempre.
Dê um exemplo prático de Durabilidade
Cenário: Sistema de pagamentos online
- Cliente finaliza compra
- Recebe confirmação de pagamento
- Servidor sofre queda de energia
-
Durabilidade em ação:
- Servidor reinicia
- Pagamento continua registrado
- Nada se perde
Mesmo com falhas, os dados confirmados estão seguros.
Single Responsibility Principle (Princípio da Responsabilidade Única)
Contexto: Cada classe deve ter uma única responsabilidade. No contexto de um banco, podemos separar as responsabilidades de gerenciar contas, clientes e transações.
Explicação: A classe Conta é responsável apenas por gerenciar o saldo e as operações de depósito e saque. A classe TransacaoService é responsável por registrar as transações. Dessa forma, cada classe tem uma única responsabilidade.
public class Conta
{
public string NumeroConta { get; set; }
public decimal Saldo { get; set; }
public void Depositar(decimal valor)
{
Saldo += valor;
}
public void Sacar(decimal valor)
{
if (Saldo >= valor)
{
Saldo -= valor;
}
else
{
throw new InvalidOperationException("Saldo insuficiente");
}
}
}
public class TransacaoService
{
public void RegistrarTransacao(Conta conta, decimal valor, string tipo)
{
// Lógica para registrar a transação no banco de dados
Console.WriteLine($"Transação registrada: {tipo} de {valor} na conta {conta.NumeroConta}");
}
}Open/Closed Principle (Princípio Aberto/Fechado)
Contexto: O sistema deve ser aberto para extensão, mas fechado para modificação. Podemos estender o comportamento do sistema sem modificar o código existente.
Explicação: A classe Conta está fechada para modificação, mas aberta para extensão. Podemos adicionar novos tipos de contas (como ContaInvestimento) sem modificar a classe Conta.
public abstract class Conta
{
public string NumeroConta { get; set; }
public decimal Saldo { get; set; }
public abstract void AplicarTaxa();
}
public class ContaCorrente : Conta
{
public override void AplicarTaxa()
{
Saldo -= 10; // Taxa mensal para conta corrente
}
}
public class ContaPoupanca : Conta
{
public override void AplicarTaxa()
{
Saldo *= 1.005m; // Juros mensais para conta poupança
}
}Liskov Substitution Principle (Princípio da Substituição de Liskov)
Contexto: Objetos de uma classe derivada devem ser capazes de substituir objetos da classe base sem alterar a corretude do programa.
Explicação: A classe ContaCorrente pode substituir a classe Conta sem alterar o comportamento esperado. O método Sacar foi sobrescrito para considerar o limite do cheque especial.
public class Conta
{
public string NumeroConta { get; set; }
public decimal Saldo { get; set; }
public virtual void Sacar(decimal valor)
{
if (Saldo >= valor)
{
Saldo -= valor;
}
else
{
throw new InvalidOperationException("Saldo insuficiente");
}
}
}
public class ContaCorrente : Conta
{
public decimal LimiteChequeEspecial { get; set; }
public override void Sacar(decimal valor)
{
if (Saldo + LimiteChequeEspecial >= valor)
{
Saldo -= valor;
}
else
{
throw new InvalidOperationException("Saldo e limite insuficientes");
}
}
}Interface Segregation Principle (Princípio da Segregação de Interfaces)
Contexto: Uma classe não deve ser forçada a implementar interfaces que não utiliza. No contexto de um banco, podemos segregar interfaces para diferentes tipos de contas.
Explicação: A interface IContaBasica contém métodos básicos para depósito e saque, enquanto IContaInvestimento contém métodos específicos para investimentos. A classe ContaCorrente implementa apenas IContaBasica, enquanto ContaInvestimento implementa ambas as interfaces.
public interface IContaBasica
{
void Depositar(decimal valor);
void Sacar(decimal valor);
}
public interface IContaInvestimento
{
void AplicarInvestimento(decimal valor);
}
public class ContaCorrente : IContaBasica
{
public decimal Saldo { get; set; }
public void Depositar(decimal valor)
{
Saldo += valor;
}
public void Sacar(decimal valor)
{
if (Saldo >= valor)
{
Saldo -= valor;
}
else
{
throw new InvalidOperationException("Saldo insuficiente");
}
}
}
public class ContaInvestimento : IContaBasica, IContaInvestimento
{
public decimal Saldo { get; set; }
public void Depositar(decimal valor)
{
Saldo += valor;
}
public void Sacar(decimal valor)
{
if (Saldo >= valor)
{
Saldo -= valor;
}
else
{
throw new InvalidOperationException("Saldo insuficiente");
}
}
public void AplicarInvestimento(decimal valor)
{
Saldo += valor * 1.1m; // Aplica um rendimento de 10%
}
}Dependency Inversion Principle (Princípio da Inversão de Dependência)
Contexto: Módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações. No contexto de um banco, podemos usar injeção de dependência para desacoplar as dependências.
Explicação: A classe ContaService depende da abstração ITransacaoService, e não de uma implementação concreta. Isso permite que diferentes serviços de transação sejam injetados sem alterar a classe ContaService.
public interface ITransacaoService
{
void RegistrarTransacao(Conta conta, decimal valor, string tipo);
}
public class TransacaoService : ITransacaoService
{
public void RegistrarTransacao(Conta conta, decimal valor, string tipo)
{
// Lógica para registrar a transação no banco de dados
Console.WriteLine($"Transação registrada: {tipo} de {valor} na conta {conta.NumeroConta}");
}
}
public class ContaService
{
private readonly ITransacaoService _transacaoService;
public ContaService(ITransacaoService transacaoService)
{
_transacaoService = transacaoService;
}
public void Depositar(Conta conta, decimal valor)
{
conta.Depositar(valor);
_transacaoService.RegistrarTransacao(conta, valor, "Depósito");
}
public void Sacar(Conta conta, decimal valor)
{
conta.Sacar(valor);
_transacaoService.RegistrarTransacao(conta, valor, "Saque");
}
}SOLID
SOLID é um acrônimo que representa cinco princípios de design de software que visam melhorar a qualidade, a manutenibilidade e a escalabilidade do código. Esses princípios foram popularizados por Robert C. Martin (também conhecido como Uncle Bob) e são amplamente utilizados na programação orientada a objetos.
Os princípios SOLID são diretrizes valiosas para criar software robusto, flexível e de fácil manutenção. Ao aplicá-los, você pode evitar muitos problemas comuns de design de software, como código rígido, frágil e difícil de entender. Em C#, esses princípios podem ser implementados usando classes, interfaces, herança e injeção de dependência, entre outras técnicas.
Por que usamos o AWS Secrets Manager?
- Segurança – Os segredos são criptografados e armazenados de forma segura, reduzindo riscos de vazamento.
- Rotação automática – Permite a rotação automática de credenciais para bancos de dados e outros serviços sem interrupções.
- Gerenciamento centralizado – Todos os segredos podem ser armazenados e gerenciados em um único local.
- Auditoria e monitoramento – Integra-se com o AWS CloudTrail para registrar acessos e alterações.
* Acesso controlado – Usa IAM policies para garantir que apenas serviços e usuários autorizados tenham acesso aos segredos. - Evita variáveis de ambiente sensíveis – Evita o armazenamento de credenciais em arquivos de configuração ou código.
Pra que serve o WAF?
✅ O AWS WAF protege aplicações contra ataques na camada 7.
✅ Pode ser integrado a CloudFront, ALB, API Gateway e outros serviços AWS.
✅ Usa regras gerenciadas da AWS ou regras customizadas.
✅ Permite bloquear SQL Injection, XSS, bots maliciosos e DDoS.
✅ Pode limitar o número de requisições por IP para mitigar ataques.
Quais são os passos do SSH?
- Inicio da conexão 2. Troca de chaves pública e privada entre cliente e servidor 3. Cliente realiza o login 4. Server verificar se essa chave pública está na sua lista de autorizados em ~/.ssh/authorized_keys 5. Server envia um desafio para o cliente 6. Cliente envia a resposta 7. Server valida a resposta e envia a chave de sessão (session key) 8. Cliente envia os comandos criptografados com a session key. 9. Server envia os resultados criptografados 10. Cliente utiliza a chave de sessão para descriptografar a resposta do servidor.
O que é Clean Architecture?
Clean Architecture é um modelo de arquitetura de software que organiza o código em camadas concéntricas para separar responsabilidades e facilitar manutenção e testes.
Quais são as principais camadas da Clean Architecture?
As principais camadas são:
- Entidades (Entities)
- Casos de Uso (Use Cases)
- Interface de Aplicação (Interface Adapters)
- Infraestrutura (Frameworks & Drivers)
O que são as entidades na Clean Architecture?
As entidades são objetos de domínio que representam as regras de negócio independentes de tecnologia ou frameworks.
public class Cliente
{
public int Id { get; set; }
public string Nome { get; set; }
}O que são os casos de uso na Clean Architecture?
Os casos de uso contêm a lógica de aplicação e coordenam a execução das regras de negócio definidas pelas entidades.
public class CriarClienteUseCase
{
private readonly IClienteRepositorio _repositorio;
public CriarClienteUseCase(IClienteRepositorio repositorio)
{
_repositorio = repositorio;
}
public void Executar(Cliente cliente)
{
_repositorio.Adicionar(cliente);
}
}Qual é o papel dos adaptadores de interface na Clean Architecture?
Os adaptadores de interface convertem dados entre a camada de casos de uso e o mundo externo, como APIs, UI e bancos de dados.
public class ClienteController
{
private readonly CriarClienteUseCase _useCase;
public ClienteController(CriarClienteUseCase useCase)
{
_useCase = useCase;
}
public void Post(Cliente cliente)
{
_useCase.Executar(cliente);
}
}Como a Clean Architecture lida com a infraestrutura?
A infraestrutura fica na camada mais externa e fornece implementações concretas para bancos de dados, frameworks web e outros serviços externos.
public class ClienteRepositorio : IClienteRepositorio
{
private readonly DbContext _context;
public ClienteRepositorio(DbContext context)
{
_context = context;
}
public void Adicionar(Cliente cliente)
{
_context.Clientes.Add(cliente);
_context.SaveChanges();
}
}O que é Hexagonal Architecture?
Hexagonal Architecture é um modelo de arquitetura de software que promove a separação entre a lógica de negócio e as dependências externas através de portas e adaptadores.
Quais são os principais componentes da Hexagonal Architecture?
Os principais componentes são:
- Domínio (Entities)
- Portas (Ports)
- Adaptadores (Adapters)
- Infraestrutura
O que são as entidades na Hexagonal Architecture?
As entidades representam o domínio central da aplicação e contêm as regras de negócio.
public class Cliente
{
public int Id { get; set; }
public string Nome { get; set; }
}O que são as portas na Hexagonal Architecture?
As portas são interfaces que definem as operações disponíveis para os casos de uso e servem como contrato entre o domínio e os adaptadores.
public interface IClienteService
{
void AdicionarCliente(Cliente cliente);
}O que são os adaptadores na Hexagonal Architecture?
Os adaptadores são implementações concretas das portas que interagem com serviços externos como bancos de dados, APIs e interfaces de usuário.
public class ClienteService : IClienteService
{
private readonly IClienteRepositorio _repositorio;
public ClienteService(IClienteRepositorio repositorio)
{
_repositorio = repositorio;
}
public void AdicionarCliente(Cliente cliente)
{
_repositorio.Adicionar(cliente);
}
}Como a Hexagonal Architecture lida com a infraestrutura?
A infraestrutura implementa os adaptadores necessários para conectar o domínio a tecnologias externas, garantindo a flexibilidade do sistema.
public class ClienteRepositorio : IClienteRepositorio
{
private readonly DbContext _context;
public ClienteRepositorio(DbContext context)
{
_context = context;
}
public void Adicionar(Cliente cliente)
{
_context.Clientes.Add(cliente);
_context.SaveChanges();
}
}Singleton
O padrão Singleton garante que uma classe tenha apenas uma instância e fornece um ponto de acesso global a essa instância. Em um banco financeiro, isso pode ser útil para gerenciar recursos compartilhados, como uma conexão de banco de dados ou um serviço de log.
public class DatabaseConnection
{
private static DatabaseConnection _instance;
private DatabaseConnection() { }
public static DatabaseConnection Instance
{
get
{
if (_instance == null)
{
_instance = new DatabaseConnection();
}
return _instance;
}
}
public void Connect()
{
// Lógica para conectar ao banco de dados
}
}
// Uso
var dbConnection = DatabaseConnection.Instance;
dbConnection.Connect();Factory Method
O Factory Method é um padrão de criação que define uma interface para criar um objeto, mas permite que as subclasses alterem o tipo de objetos que serão criados. Em um banco financeiro, isso pode ser útil para criar diferentes tipos de contas bancárias (conta corrente, poupança, etc.).
public abstract class Account
{
public abstract void Deposit(decimal amount);
}
public class SavingsAccount : Account
{
public override void Deposit(decimal amount)
{
// Lógica para depósito em conta poupança
}
}
public class CheckingAccount : Account
{
public override void Deposit(decimal amount)
{
// Lógica para depósito em conta corrente
}
}
public abstract class AccountFactory
{
public abstract Account CreateAccount();
}
public class SavingsAccountFactory : AccountFactory
{
public override Account CreateAccount()
{
return new SavingsAccount();
}
}
public class CheckingAccountFactory : AccountFactory
{
public override Account CreateAccount()
{
return new CheckingAccount();
}
}
// Uso
AccountFactory factory = new SavingsAccountFactory();
Account account = factory.CreateAccount();
account.Deposit(1000);Observer
O padrão Observer permite que um objeto notifique outros objetos sobre mudanças em seu estado. Em um banco financeiro, isso pode ser útil para notificar clientes sobre mudanças em suas contas, como transações ou saldos.
public interface IObserver
{
void Update(string message);
}
public class Customer : IObserver
{
public void Update(string message)
{
Console.WriteLine($"Notificação recebida: {message}");
}
}
public class Account
{
private List<IObserver> _observers = new List<IObserver>();
public void Attach(IObserver observer)
{
_observers.Add(observer);
}
public void Detach(IObserver observer)
{
_observers.Remove(observer);
}
public void Notify(string message)
{
foreach (var observer in _observers)
{
observer.Update(message);
}
}
public void Deposit(decimal amount)
{
// Lógica para depósito
Notify($"Depósito de {amount} realizado.");
}
}
// Uso
var account = new Account();
var customer = new Customer();
account.Attach(customer);
account.Deposit(1000);Strategy
O padrão Strategy permite que você defina uma família de algoritmos, encapsule cada um deles e os torne intercambiáveis. Em um banco financeiro, isso pode ser útil para implementar diferentes estratégias de cálculo de juros ou taxas.
public interface IInterestStrategy
{
decimal CalculateInterest(decimal balance);
}
public class SavingsInterestStrategy : IInterestStrategy
{
public decimal CalculateInterest(decimal balance)
{
return balance * 0.02m; // 2% de juros
}
}
public class CheckingInterestStrategy : IInterestStrategy
{
public decimal CalculateInterest(decimal balance)
{
return balance * 0.01m; // 1% de juros
}
}
public class Account
{
private IInterestStrategy _interestStrategy;
public Account(IInterestStrategy interestStrategy)
{
_interestStrategy = interestStrategy;
}
public void SetInterestStrategy(IInterestStrategy interestStrategy)
{
_interestStrategy = interestStrategy;
}
public decimal CalculateInterest(decimal balance)
{
return _interestStrategy.CalculateInterest(balance);
}
}
// Uso
var account = new Account(new SavingsInterestStrategy());
decimal interest = account.CalculateInterest(1000);
Console.WriteLine($"Juros calculados: {interest}");Decorator
O padrão Decorator permite adicionar comportamentos a objetos individualmente, de forma dinâmica, sem afetar o comportamento de outros objetos da mesma classe. Em um banco financeiro, isso pode ser útil para adicionar funcionalidades extras a contas, como seguros ou benefícios.
public abstract class Account
{
public abstract decimal GetBalance();
}
public class BasicAccount : Account
{
private decimal _balance;
public BasicAccount(decimal balance)
{
_balance = balance;
}
public override decimal GetBalance()
{
return _balance;
}
}
public abstract class AccountDecorator : Account
{
protected Account _account;
public AccountDecorator(Account account)
{
_account = account;
}
public override decimal GetBalance()
{
return _account.GetBalance();
}
}
public class InsuranceDecorator : AccountDecorator
{
public InsuranceDecorator(Account account) : base(account) { }
public override decimal GetBalance()
{
return base.GetBalance() - 50; // Custo do seguro
}
}
// Uso
Account account = new BasicAccount(1000);
account = new InsuranceDecorator(account);
Console.WriteLine($"Saldo com seguro: {account.GetBalance()}");Command
O padrão Command encapsula uma solicitação como um objeto, permitindo que você parametrize clientes com diferentes solicitações, enfileire ou registre solicitações e suporte operações que podem ser desfeitas. Em um banco financeiro, isso pode ser útil para implementar transações que podem ser desfeitas (rollback).
public interface ICommand
{
void Execute();
void Undo();
}
public class DepositCommand : ICommand
{
private Account _account;
private decimal _amount;
public DepositCommand(Account account, decimal amount)
{
_account = account;
_amount = amount;
}
public void Execute()
{
_account.Deposit(_amount);
}
public void Undo()
{
_account.Withdraw(_amount);
}
}
public class Account
{
public decimal Balance { get; private set; }
public void Deposit(decimal amount)
{
Balance += amount;
}
public void Withdraw(decimal amount)
{
Balance -= amount;
}
}
// Uso
var account = new Account();
var depositCommand = new DepositCommand(account, 1000);
depositCommand.Execute();
Console.WriteLine($"Saldo após depósito: {account.Balance}");
depositCommand.Undo();
Console.WriteLine($"Saldo após desfazer depósito: {account.Balance}");Facade
O padrão Facade fornece uma interface simplificada para um conjunto de interfaces em um subsistema. Em um banco financeiro, isso pode ser útil para fornecer uma interface simples para operações complexas, como abertura de contas, transferências, etc.
public class AccountService
{
public void CreateAccount(string accountType)
{
// Lógica para criar uma conta
}
}
public class TransactionService
{
public void Transfer(decimal amount, string fromAccount, string toAccount)
{
// Lógica para transferência
}
}
public class BankingFacade
{
private AccountService _accountService;
private TransactionService _transactionService;
public BankingFacade()
{
_accountService = new AccountService();
_transactionService = new TransactionService();
}
public void OpenAccount(string accountType)
{
_accountService.CreateAccount(accountType);
}
public void TransferMoney(decimal amount, string fromAccount, string toAccount)
{
_transactionService.Transfer(amount, fromAccount, toAccount);
}
}
// Uso
var bankingFacade = new BankingFacade();
bankingFacade.OpenAccount("Savings");
bankingFacade.TransferMoney(1000, "12345", "67890");Chain of Responsibility
O padrão Chain of Responsibility permite que você crie uma cadeia de objetos para processar uma solicitação. Cada objeto na cadeia decide se processa a solicitação ou a passa para o próximo objeto. Em um banco financeiro, isso pode ser útil para aprovação de empréstimos ou validação de transações.
public abstract class Approver
{
protected Approver _nextApprover;
public void SetNextApprover(Approver nextApprover)
{
_nextApprover = nextApprover;
}
public abstract void ProcessLoanRequest(decimal amount);
}
public class Manager : Approver
{
public override void ProcessLoanRequest(decimal amount)
{
if (amount <= 10000)
{
Console.WriteLine("Empréstimo aprovado pelo Gerente.");
}
else if (_nextApprover != null)
{
_nextApprover.ProcessLoanRequest(amount);
}
}
}
public class Director : Approver
{
public override void ProcessLoanRequest(decimal amount)
{
if (amount <= 50000)
{
Console.WriteLine("Empréstimo aprovado pelo Diretor.");
}
else if (_nextApprover != null)
{
_nextApprover.ProcessLoanRequest(amount);
}
}
}
public class CEO : Approver
{
public override void ProcessLoanRequest(decimal amount)
{
Console.WriteLine("Empréstimo aprovado pelo CEO.");
}
}
// Uso
var manager = new Manager();
var director = new Director();
var ceo = new CEO();
manager.SetNextApprover(director);
director.SetNextApprover(ceo);
manager.ProcessLoanRequest(15000); // Aprovado pelo Diretor
manager.ProcessLoanRequest(75000); // Aprovado pelo CEOTemplate Method
O padrão Template Method define o esqueleto de um algoritmo em uma operação, adiando alguns passos para as subclasses. Em um banco financeiro, isso pode ser útil para implementar processos padronizados, como abertura de contas ou cálculo de taxas.
public abstract class AccountOpeningProcess
{
public void OpenAccount()
{
VerifyIdentity();
ValidateDocuments();
CreateAccount();
NotifyCustomer();
}
protected abstract void VerifyIdentity();
protected abstract void ValidateDocuments();
private void CreateAccount()
{
Console.WriteLine("Conta criada com sucesso.");
}
private void NotifyCustomer()
{
Console.WriteLine("Cliente notificado sobre a abertura da conta.");
}
}
public class SavingsAccountOpening : AccountOpeningProcess
{
protected override void VerifyIdentity()
{
Console.WriteLine("Verificando identidade para conta poupança.");
}
protected override void ValidateDocuments()
{
Console.WriteLine("Validando documentos para conta poupança.");
}
}
public class CheckingAccountOpening : AccountOpeningProcess
{
protected override void VerifyIdentity()
{
Console.WriteLine("Verificando identidade para conta corrente.");
}
protected override void ValidateDocuments()
{
Console.WriteLine("Validando documentos para conta corrente.");
}
}
// Uso
AccountOpeningProcess savingsProcess = new SavingsAccountOpening();
savingsProcess.OpenAccount();
AccountOpeningProcess checkingProcess = new CheckingAccountOpening();
checkingProcess.OpenAccount();State
O padrão State permite que um objeto altere seu comportamento quando seu estado interno muda. Em um banco financeiro, isso pode ser útil para gerenciar o estado de uma conta (ativa, bloqueada, encerrada) e definir comportamentos específicos para cada estado.
public abstract class AccountState
{
public abstract void Deposit(decimal amount, Account account);
public abstract void Withdraw(decimal amount, Account account);
}
public class ActiveState : AccountState
{
public override void Deposit(decimal amount, Account account)
{
account.Balance += amount;
Console.WriteLine($"Depósito de {amount} realizado. Novo saldo: {account.Balance}");
}
public override void Withdraw(decimal amount, Account account)
{
if (account.Balance >= amount)
{
account.Balance -= amount;
Console.WriteLine($"Saque de {amount} realizado. Novo saldo: {account.Balance}");
}
else
{
Console.WriteLine("Saldo insuficiente.");
}
}
}
public class BlockedState : AccountState
{
public override void Deposit(decimal amount, Account account)
{
Console.WriteLine("Conta bloqueada. Depósito não permitido.");
}
public override void Withdraw(decimal amount, Account account)
{
Console.WriteLine("Conta bloqueada. Saque não permitido.");
}
}
public class Account
{
public decimal Balance { get; set; }
public AccountState State { get; set; }
public Account()
{
State = new ActiveState(); // Estado inicial
}
public void Deposit(decimal amount)
{
State.Deposit(amount, this);
}
public void Withdraw(decimal amount)
{
State.Withdraw(amount, this);
}
public void Block()
{
State = new BlockedState();
Console.WriteLine("Conta bloqueada.");
}
public void Unblock()
{
State = new ActiveState();
Console.WriteLine("Conta desbloqueada.");
}
}
// Uso
var account = new Account();
account.Deposit(1000);
account.Withdraw(500);
account.Block();
account.Deposit(200); // Não permitido
account.Withdraw(100); // Não permitido
account.Unblock();
account.Deposit(200); // Permitido novamenteProxy
O padrão Proxy fornece um substituto ou um espaço reservado para outro objeto para controlar o acesso a ele. Em um banco financeiro, isso pode ser útil para controlar o acesso a operações sensíveis, como transferências ou consultas de saldo.
public interface IBankAccount
{
void Deposit(decimal amount);
void Withdraw(decimal amount);
decimal GetBalance();
}
public class RealBankAccount : IBankAccount
{
private decimal _balance;
public void Deposit(decimal amount)
{
_balance += amount;
Console.WriteLine($"Depósito de {amount} realizado. Novo saldo: {_balance}");
}
public void Withdraw(decimal amount)
{
if (_balance >= amount)
{
_balance -= amount;
Console.WriteLine($"Saque de {amount} realizado. Novo saldo: {_balance}");
}
else
{
Console.WriteLine("Saldo insuficiente.");
}
}
public decimal GetBalance()
{
return _balance;
}
}
public class BankAccountProxy : IBankAccount
{
private RealBankAccount _realAccount;
private string _userRole;
public BankAccountProxy(string userRole)
{
_userRole = userRole;
}
public void Deposit(decimal amount)
{
if (_userRole == "Admin")
{
if (_realAccount == null)
{
_realAccount = new RealBankAccount();
}
_realAccount.Deposit(amount);
}
else
{
Console.WriteLine("Acesso negado. Somente administradores podem depositar.");
}
}
public void Withdraw(decimal amount)
{
if (_userRole == "Admin")
{
if (_realAccount == null)
{
_realAccount = new RealBankAccount();
}
_realAccount.Withdraw(amount);
}
else
{
Console.WriteLine("Acesso negado. Somente administradores podem sacar.");
}
}
public decimal GetBalance()
{
if (_realAccount == null)
{
_realAccount = new RealBankAccount();
}
return _realAccount.GetBalance();
}
}
// Uso
IBankAccount account = new BankAccountProxy("User");
account.Deposit(1000); // Acesso negado
account = new BankAccountProxy("Admin");
account.Deposit(1000); // PermitidoMemento
O padrão Memento permite capturar e externalizar o estado interno de um objeto sem violar o encapsulamento, para que o objeto possa ser restaurado para esse estado posteriormente. Em um banco financeiro, isso pode ser útil para implementar funcionalidades de “desfazer” em transações.
public class BankAccountMemento
{
public decimal Balance { get; }
public BankAccountMemento(decimal balance)
{
Balance = balance;
}
}
public class BankAccount
{
private decimal _balance;
public BankAccount(decimal balance)
{
_balance = balance;
}
public void Deposit(decimal amount)
{
_balance += amount;
Console.WriteLine($"Depósito de {amount} realizado. Novo saldo: {_balance}");
}
public void Withdraw(decimal amount)
{
if (_balance >= amount)
{
_balance -= amount;
Console.WriteLine($"Saque de {amount} realizado. Novo saldo: {_balance}");
}
else
{
Console.WriteLine("Saldo insuficiente.");
}
}
public BankAccountMemento Save()
{
return new BankAccountMemento(_balance);
}
public void Restore(BankAccountMemento memento)
{
_balance = memento.Balance;
Console.WriteLine($"Conta restaurada para o saldo: {_balance}");
}
}
// Uso
var account = new BankAccount(1000);
var memento = account.Save(); // Salva o estado atual
account.Deposit(500);
account.Withdraw(200);
account.Restore(memento); // Restaura para o estado salvoAdapter
O padrão Adapter é um padrão estrutural que permite que classes com interfaces incompatíveis trabalhem juntas. Ele atua como uma ponte entre duas interfaces, convertendo a interface de uma classe em outra interface esperada pelo cliente. Em um contexto de banco financeiro, o Adapter pode ser útil para integrar sistemas legados, APIs de terceiros ou serviços externos que possuem interfaces diferentes das esperadas pela aplicação.
Mediator
O padrão Mediator é um padrão comportamental que promove o baixo acoplamento entre objetos ao centralizar a comunicação entre eles em um único objeto, chamado de Mediator. Em vez de os objetos se comunicarem diretamente entre si, eles se comunicam através do Mediator, que coordena as interações. Isso é especialmente útil em sistemas complexos, como um banco financeiro, onde vários componentes precisam interagir de forma coordenada.
Qual a diferença das linguagens interpretadas, compiladas e híbridas?
Na linguagem compilada, primeiramente ela é compilada e convertida para código de máquina diretamente (assembly), por conta disso muitas vezes ele é mais performática do que as demais pois já está traduzido, esse processo gerar um executavel. Exemplo: C, C++, Rust e Go.
Na linguagem interpretada, o código é lido linha por linha em tempo de execução, não existe o processo de compilação. A portabilidade é boa desde que tenha um interpretador disponível. Pode ser lenta, porque o código é traduzido em tempo de execução. Exemplo: Python, JavaScript, Ruby, Php
Na linguage híbrida, é combinado os dois aspectos. No Java por exemplo, o código é converto para bytecode que é interpretado pela JVM. O C# é compilado para uma linguagem intermediárias, que é executado pelo .NET Common Language Runtime (CLR)
Resumo
Linguagens Compiladas: Código fonte é compilado para um executável antes da execução. Geralmente mais rápido, mas menos portátil.
Linguagens Interpretadas: Código fonte é executado diretamente por um interpretador. Geralmente mais portátil, mas pode ser mais lento.
Linguagens Híbridas: Combinam compilação e interpretação, oferecendo um equilíbrio entre desempenho e portabilidade.
Quais os princípios do clean coding?
Qual a sua experiencia com frameworks de teste e controle de qualidade?
Quais frameworks já trabalhou em seu último projeto?
Já trabalhou com testes de carga e/ou teste unitário?
Você preza pela entrega com maior qualidade ou entrega básica?
O que é escalabilidade horizontal e vertical?
Que relação há entre escalabilidade e ferramentas como Docker?
O que são testes de carga e como você montaria um?
Como você escolhe a arquitetura que você irá utilizar em uma aplicação?
Como você escreveria uma query SQL para selecionar da tabela users os usuários cujo nomes começassem por R?
O que é um JOIN?
O que você costuma fazer pra melhorar o desempenho do seu código?
Você tem experiência com coding review?
Definições de requisitos e arquiteturas modernas
Quais situações você diria que seria bom analisar para para escolher entre um banco SQL e um NoSQL?
Como você escala o seu serviço?
Você sabe comandos git? Pode me dar um exemplo?
Mensageria
Cite algo que você se orgulha de ter feito, ou solucionado?
Qual é a sua opinião sobre testes unitários?
Como você lidou com alguma adversidade no trabalho?
Ferramentas de troubleshooting, datadog
Um desafio marcante na sua carreira?
Como você projetaria um sistema escalável?
Resposta esperada: Usaria técnicas como:
Balanceamento de Carga: Distribuir a carga entre múltiplos servidores.
Microsserviços: Dividir o sistema em serviços independentes que podem ser escalados separadamente.
Cache: Usar caches (ex.: Redis) para reduzir a carga no banco de dados.
Banco de Dados Distribuído: Usar bancos como Cassandra ou MongoDB para distribuir dados.
Qual a diferença entre escalabilidade e desempenho?
Resposta esperada: Desempenho refere-se à velocidade e eficiência de um sistema sob uma carga específica, enquanto escalabilidade refere-se à capacidade do sistema de lidar com aumentos de carga.
Como lidar com gargalos em um sistema escalável?
Resposta esperada: Identificar gargalos (ex.: banco de dados, rede) e aplicar soluções como:
Sharding: Dividir o banco de dados em partes menores.
CDN: Usar Content Delivery Networks para reduzir a carga no servidor.
Filas de Mensagens: Usar RabbitMQ ou Kafka para processamento assíncrono.
Quais são as melhores práticas para garantir a segurança de um sistema?
Autenticação e Autorização: Usar OAuth, JWT ou outros mecanismos para garantir que apenas usuários autorizados acessem recursos.
Criptografia: Criptografar dados em trânsito (TLS/SSL) e em repouso (AES).
Validação de Entrada: Prevenir SQL Injection, XSS e outros ataques validando e sanitizando entradas.
Atualizações: Manter sistemas e bibliotecas atualizados para corrigir vulnerabilidades.
O que é SQL Injection e como prevenir?
Resposta esperada: SQL Injection é um ataque onde um invasor insere comandos SQL maliciosos em entradas de dados. Prevenção:
Usar prepared statements e parameterized queries.
Validar e sanitizar entradas.
Usar ORMs (Object-Relational Mappers) que abstraem consultas SQL.
O que é CORS (Cross-Origin Resource Sharing) e como configurá-lo corretamente?
Resposta esperada: CORS é um mecanismo que permite que recursos em um domínio sejam acessados por outro domínio. Configuração correta:
Definir cabeçalhos HTTP como Access-Control-Allow-Origin.
Restringir origens permitidas e métodos HTTP (GET, POST, etc.).
Como proteger APIs RESTful?
Resposta esperada:
Usar HTTPS para criptografar comunicações.
Implementar autenticação (ex.: OAuth 2.0, JWT).
Validar e limitar requisições (Rate Limiting).
Usar tokens CSRF para prevenir ataques de falsificação de solicitação entre sites.
O que é um ataque DDoS e como mitigá-lo?
Resposta esperada: Um ataque DDoS (Distributed Denial of Service) sobrecarrega um sistema com tráfego falso. Mitigação:
Usar serviços de proteção como Cloudflare ou AWS Shield.
Configurar firewalls e limitar tráfego suspeito.
Distribuir a carga com CDNs e balanceadores de carga.
Qual a diferença entre bancos relacionais e não relacionais?
Bancos Relacionais (SQL): Armazenam dados em tabelas com esquemas fixos (ex.: MySQL, PostgreSQL). Ideais para dados estruturados e transações ACID.
Bancos Não Relacionais (NoSQL): Armazenam dados em formatos flexíveis (ex.: documentos, chave-valor, grafos). Ideais para dados não estruturados e escalabilidade horizontal (ex.: MongoDB, Cassandra).
O que são índices em bancos de dados e quando usá-los?
Resposta esperada: Índices são estruturas que aceleram consultas, mas podem aumentar o tempo de inserção/atualização. Usar em colunas frequentemente consultadas (ex.: chaves primárias, campos de busca).
O que é normalização de banco de dados e quais são as formas normais?
Resposta esperada: Normalização é o processo de organizar dados para reduzir redundância e inconsistências. Formas normais:
1NF: Eliminar duplicidades e garantir atomicidade.
2NF: Remover dependências parciais.
3NF: Remover dependências transitivas.
Como lidar com transações em bancos de dados?
Resposta esperada: Usar transações para garantir ACID (Atomicidade, Consistência, Isolamento, Durabilidade). Exemplo:
BEGIN TRANSACTION; UPDATE contas SET saldo = saldo - 100 WHERE id = 1; UPDATE contas SET saldo = saldo + 100 WHERE id = 2; COMMIT;
O que é sharding e quando usá-lo?
Resposta esperada: Sharding é a divisão de um banco de dados em partes menores (shards) para distribuir a carga. Usar quando o banco de dados cresce demais para um único servidor.
Qual a diferença entre Redis e um banco de dados tradicional?
Resposta esperada: Redis é um banco de dados em memória, ideal para caching e operações de alta velocidade. Bancos tradicionais (ex.: MySQL) são baseados em disco e mais adequados para armazenamento persistente e consultas complexas.
O que é CAP Theorem?
Resposta esperada: O CAP Theorem afirma que um sistema distribuído pode garantir apenas dois dos três aspectos: Consistência, Disponibilidade e Tolerância a Partições. Exemplos:
CP: MongoDB (Consistência e Tolerância a Partições).
AP: Cassandra (Disponibilidade e Tolerância a Partições).
A CA (consistency and availability) database can’t exist in practice because partitions between nodes are unavoidable in distributed systems. This means that CA databases can’t provide fault tolerance.
Como você otimizaria uma consulta lenta em um banco de dados?
Resposta esperada:
Analisar o plano de execução da consulta.
Adicionar índices nas colunas usadas nas cláusulas WHERE e JOIN.
Evitar SELECT * e buscar apenas colunas necessárias.
Particionar tabelas grandes.
Como garantir a consistência de dados em um sistema distribuído?
Resposta esperada:
Usar transações distribuídas ou padrões como Saga.
Implementar mecanismos de reconciliação e idempotência.
Usar filas de mensagens para garantir processamento ordenado.
Como você implementaria autenticação em uma API?
Resposta esperada:
Usar JWT (JSON Web Tokens) para autenticação stateless.
Implementar OAuth 2.0 para autorização.
Armazenar senhas com hash (ex.: bcrypt) e usar HTTPS.
Como você garantiria a consistência de dados em um sistema distribuído baseado em microsserviços?
Event Sourcing: Armazenar todos os eventos que alteram o estado do sistema, permitindo reconstruir o estado atual a qualquer momento.
Sagas: Usar padrões de Saga para gerenciar transações distribuídas. Cada microsserviço executa sua parte da transação e publica eventos para o próximo passo.
Consenso Distribuído: Usar algoritmos como Paxos ou Raft para garantir consistência entre nós.
CQRS (Command Query Responsibility Segregation): Separar leituras e escritas para garantir que as consultas não afetem a consistência das operações de escrita.
Quais estratégias você usaria para monitorar e depurar microsserviços em produção?
Resposta:
Centralização de Logs: Usar ferramentas como ELK Stack (Elasticsearch, Logstash, Kibana) ou Graylog para agregar logs de todos os microsserviços.
Tracing Distribuído: Implementar tracing com ferramentas como Jaeger ou Zipkin para rastrear requisições entre microsserviços.
Monitoramento em Tempo Real: Usar Prometheus e Grafana para monitorar métricas como latência, taxa de erro e uso de recursos.
Alertas Configuráveis: Configurar alertas para métricas críticas (ex.: alta latência, aumento de erros) usando ferramentas como PagerDuty ou Opsgenie.
Newlic, Data dog???
Em que cenários você escolheria um banco de dados NoSQL em vez de um SQL?
Dados Não Estruturados: Quando os dados não seguem um esquema fixo (ex.: documentos JSON).
Alta Escalabilidade: Para sistemas que precisam escalar horizontalmente (ex.: Cassandra, MongoDB).
Baixa Latência: Quando a velocidade de leitura/escrita é crítica (ex.: Redis para caching).
Grandes Volumes de Dados: Para big data ou sistemas de análise em tempo real (ex.: Elasticsearch).
Como você otimizaria uma consulta lenta em um banco de dados relacional?
Índices: Adicionar índices nas colunas usadas em cláusulas WHERE, JOIN e ORDER BY.
Análise de Plano de Execução: Usar EXPLAIN (em SQL) para identificar gargalos.
Normalização/Desnormalização: Avaliar se a normalização está causando joins excessivos e considerar desnormalização para consultas frequentes.
Particionamento: Dividir tabelas grandes em partições menores (ex.: por data).
Dê um exemplo de como você aplicou o princípio da Inversão de Dependência (DIP) em um projeto real.
Em um sistema de pagamentos, criei uma interface PaymentGateway que define métodos como processPayment() e refundPayment(). As implementações concretas (ex.: PaypalGateway, StripeGateway) dependem dessa interface, e o código principal depende apenas da abstração, não das implementações. Isso facilita a troca de gateways sem modificar o código principal.
Como você garante que o código escrito por sua equipe siga as boas práticas de Clean Code?
Code Reviews: Revisões de código para garantir que padrões como nomes significativos, funções pequenas e responsabilidade única sejam seguidos.
Linting e Formatação Automática: Usar ferramentas como ESLint, Prettier ou Black para garantir consistência.
Testes Automatizados: Incentivar a escrita de testes unitários e de integração.
Pair Programming: Trabalhar em pares para compartilhar conhecimento e garantir qualidade.
Desenhe a arquitetura de um sistema de streaming de vídeo que precisa escalar para milhões de usuários.
Frontend: CDN para distribuir conteúdo estático (ex.: vídeos, imagens).
Backend:
Microsserviços para gerenciar usuários, catálogo de vídeos e recomendações.
Kafka para processar eventos em tempo real (ex.: visualizações, interações).
Banco de Dados:
SQL para dados transacionais (ex.: usuários, pagamentos).
NoSQL para dados não estruturados (ex.: metadados de vídeos).
Cache: Redis para armazenar dados frequentemente acessados (ex.: listas de reprodução).
Monitoramento: Prometheus e Grafana para métricas em tempo real.
Escreva um algoritmo para detectar ciclos em um grafo direcionado.
def has_cycle(graph):
visited = set()
recursion_stack = set()
def dfs(node):
if node in recursion_stack:
return True
if node in visited:
return False
visited.add(node)
recursion_stack.add(node)
for neighbor in graph[node]:
if dfs(neighbor):
return True
recursion_stack.remove(node)
return False
for node in graph:
if dfs(node):
return True
return FalseComo você garantiria a alta disponibilidade de uma aplicação usando Kubernetes?
Replicação: Configurar múltiplas réplicas de pods para garantir tolerância a falhas.
Load Balancing: Usar serviços do Kubernetes para distribuir tráfego entre pods.
Health Checks: Configurar probes (liveness e readiness) para monitorar a saúde dos pods.
Auto-scaling: Usar Horizontal Pod Autoscaler (HPA) para ajustar o número de pods com base na carga.
Como você implementaria um pipeline de CI/CD para um sistema baseado em microsserviços?
Integração Contínua (CI):
Usar ferramentas como Jenkins, GitLab CI ou GitHub Actions.
Executar testes unitários e de integração automaticamente em cada commit.
Entrega Contínua (CD):
Automatizar o deploy em ambientes de staging e produção usando Kubernetes ou Terraform.
Implementar rollback automático em caso de falha.
Segurança:
Verificar vulnerabilidades com ferramentas como Snyk ou OWASP ZAP.
Usar secrets management (ex.: HashiCorp Vault) para proteger credenciais
Como você lideraria um time técnico para garantir a entrega de um projeto complexo dentro do prazo?
Planejamento: Dividir o projeto em tarefas menores e priorizá-las.
Comunicação: Realizar reuniões diárias (stand-ups) para acompanhar o progresso.
Delegação: Atribuir tarefas com base nas habilidades de cada membro.
Gestão de Riscos: Identificar possíveis obstáculos e planejar contingências.
Como você explicaria um conceito técnico complexo para um stakeholder não técnico?
Usar analogias simples (ex.: comparar microsserviços com equipes especializadas em uma empresa).
Focar nos benefícios e impactos, não nos detalhes técnicos.
Usar visualizações (ex.: diagramas, fluxos) para facilitar o entendimento.
Como você garantiria a segurança de uma API RESTful exposta publicamente?
Autenticação e Autorização: Usar OAuth 2.0 ou JWT para gerenciar acesso.
HTTPS: Garantir que todas as comunicações sejam criptografadas.
Validação de Entrada: Sanitizar e validar todas as entradas para prevenir SQL Injection e XSS.
Rate Limiting: Limitar o número de requisições por usuário para evitar ataques de negação de serviço (DDoS).
Quais são as vulnerabilidades mais comuns listadas no OWASP Top 10 e como você as preveniria?
Injeção (SQL Injection): Usar prepared statements e ORMs.
Quebra de Autenticação: Implementar autenticação forte e MFA (Multi-Factor Authentication).
Exposição de Dados Sensíveis: Criptografar dados em trânsito e em repouso.
XSS (Cross-Site Scripting): Sanitizar entradas e usar Content Security Policy (CSP).
Qual a diferença entre HTTP/1.1, HTTP/2 e HTTP/3?
HTTP/1.1:
Conexões persistentes, mas ainda sofre com o problema de “head-of-line blocking”.
Requisições e respostas são textuais, o que aumenta a sobrecarga.
HTTP/2:
Multiplexação: várias requisições/respostas podem ser enviadas simultaneamente em uma única conexão.
Compressão de cabeçalhos (HPACK) para reduzir overhead.
Priorização de streams para melhorar o desempenho.
HTTP/3:
Usa QUIC (baseado em UDP) em vez de TCP, eliminando o “head-of-line blocking”.
Conexões mais rápidas e seguras, com criptografia integrada.
Como o HTTP/2 melhora o desempenho em comparação ao HTTP/1.1?
Multiplexação: Permite enviar múltiplas requisições/respostas em paralelo, reduzindo a latência.
Compressão de Cabeçalhos: Reduz o tamanho das requisições, economizando largura de banda.
Server Push: O servidor pode enviar recursos ao cliente antes que eles sejam solicitados.
Quando você escolheria um banco de dados SQL em vez de um NoSQL?
Quando os dados são estruturados e relacionamentos complexos são necessários.
Para garantir consistência e integridade dos dados (ACID).
Em sistemas que exigem transações complexas (ex.: sistemas financeiros).
Explique a diferença entre chave primária e chave estrangeira.
Chave Primária: Identificador único de uma linha em uma tabela. Não pode ser nula e deve ser única.
Chave Estrangeira: Coluna que referencia a chave primária de outra tabela, estabelecendo um relacionamento entre tabelas.
O que são testes unitários e por que são importantes?
Testes unitários verificam o comportamento de unidades individuais de código (ex.: funções, métodos).
Importância:
Garantem que o código funcione conforme o esperado.
Facilitam a refatoração e a detecção precoce de bugs.
Servem como documentação viva do código.
Como você garantiria a cobertura de testes em um projeto?
Usar ferramentas de cobertura de código (ex.: JaCoCo para Java, Coverage.py para Python).
Definir métricas mínimas de cobertura (ex.: 80%).
Integrar testes no pipeline de CI/CD para garantir que novos códigos sejam testados.
Explique os quatro pilares da Orientação a Objetos.
Encapsulamento: Esconder detalhes internos e expor apenas interfaces.
Herança: Uma classe pode herdar atributos e métodos de outra.
Polimorfismo: Objetos de diferentes classes podem ser tratados como objetos de uma classe base.
Abstração: Simplificar complexidades ao modelar classes que representam conceitos do mundo real.
Dê um exemplo de como você usaria herança e composição em um projeto.
Herança: Uma classe Veiculo com métodos comuns, e classes Carro e Moto que herdam de Veiculo.
Composição: Uma classe Carro que contém um objeto Motor e um objeto Roda, em vez de herdar essas características.
Explique como o Merge Sort funciona e qual sua complexidade de tempo.
Funcionamento: Divide a lista em sublistas menores, ordena cada sublista e depois as combina (merge) em uma lista ordenada.
Complexidade: O(n log n) no pior caso.
Qual a diferença entre uma lista e um conjunto (set)?
Lista: Ordenada, permite duplicatas e acesso por índice.
Conjunto: Não ordenado, não permite duplicatas e otimizado para buscas.
Quando você usaria uma árvore binária em vez de uma lista?
Quando é necessário realizar buscas, inserções e remoções eficientes (O(log n) em árvores balanceadas).
Descreva cada um dos princípios SOLID e dê um exemplo de aplicação.
S (Single Responsibility): Uma classe deve ter apenas uma razão para mudar.
Exemplo: Uma classe Relatorio que só gera relatórios, sem manipular dados.
O (Open/Closed): Entidades devem estar abertas para extensão, mas fechadas para modificação.
Exemplo: Usar interfaces para permitir novas implementações sem alterar código existente.
L (Liskov Substitution): Subclasses devem ser substituíveis por suas classes base.
Exemplo: Uma classe Pato que herda de Ave deve poder voar se Ave voar.
I (Interface Segregation): Interfaces específicas são melhores que interfaces genéricas.
Exemplo: Interfaces separadas para Imprimivel e Digitalizavel.
D (Dependency Inversion): Dependa de abstrações, não de implementações concretas.
Exemplo: Usar uma interface Repositorio em vez de uma classe RepositorioSQL.
Como o princípio da Responsabilidade Única (SRP) pode melhorar a manutenção do código?
Facilita a identificação de bugs, pois cada classe tem uma única responsabilidade.
Torna o código mais modular e reutilizável.
Dê um exemplo de uso do padrão Singleton e discuta suas vantagens e desvantagens.
Exemplo: Uma classe Logger que garante apenas uma instância em todo o sistema.
Vantagens: Controle centralizado de recursos compartilhados.
Desvantagens: Pode dificultar testes e criar acoplamento.
Como o padrão Strategy pode ser aplicado em um sistema de pagamentos?
Exemplo: Criar estratégias diferentes para métodos de pagamento (ex.: PagamentoCartao, PagamentoBoleto), permitindo trocar o algoritmo de pagamento em tempo de execução.
Quais são as vantagens e desvantagens de uma arquitetura baseada em microsserviços?
Vantagens:
Escalabilidade independente.
Facilidade de manutenção e deploy.
Desvantagens:
Complexidade na gestão de comunicação e consistência de dados.
Overhead de infraestrutura.
Como você lidaria com a comunicação entre microserviços?
Usar mensageria (ex.: Kafka, RabbitMQ) para comunicação assíncrona.
Implementar APIs RESTful ou gRPC para comunicação síncrona.
O que é REST e quais são suas principais características?
REST: Um estilo arquitetural para sistemas distribuídos, baseado em HTTP.
Características:
Stateless: Cada requisição contém todas as informações necessárias.
Recursos identificados por URIs.
Operações padrão (GET, POST, PUT, DELETE).
Como você projetaria uma API RESTful para um sistema de gerenciamento de tarefas?
Recursos:
GET /tasks: Listar tarefas.
POST /tasks: Criar uma nova tarefa.
PUT /tasks/{id}: Atualizar uma tarefa.
DELETE /tasks/{id}: Excluir uma tarefa.
Autenticação: Usar JWT ou OAuth 2.0.
Por que usar Docker em um ambiente de desenvolvimento?
Isolamento de dependências.
Facilidade de replicação de ambientes.
Integração com CI/CD.
NGINX
Servir como proxy reverso, balanceador de carga e servidor web.
Melhorar desempenho e segurança.
Como você configuraria o Let’s Encrypt para fornecer TLS em um servidor web?
Usar o Certbot para gerar e renovar certificados automaticamente.
Configurar o NGINX para usar os certificados.
Como você lida com prazos apertados e mudanças de requisitos?
Priorizar tarefas críticas.
Comunicar claramente com stakeholders sobre impactos e expectativas.
Dê um exemplo de como você resolveu um conflito em equipe.
Exemplo: Mediar uma discussão entre desenvolvedores sobre a abordagem técnica, ouvindo ambos os lados e propondo uma solução consensual.
Como você organizaria o desenvolvimento de um projeto usando Scrum?
Dividir o projeto em sprints de 2-4 semanas.
Realizar reuniões diárias (stand-ups), planejamento de sprint e retrospectivas.
Qual a importância das revisões de código (code reviews) em um time?
Garantir qualidade e consistência do código.
Compartilhar conhecimento e boas práticas.
Descreva um projeto desafiador em que você trabalhou e como você resolveu os problemas.
Como você lidou com um bug crítico em produção?
Como você decide entre usar um banco de dados relacional ou não relacional em um projeto?
Avaliar a estrutura dos dados, a necessidade de transações e a escalabilidade.
Em um projeto com restrições de tempo, como você prioriza entre entregar funcionalidades e garantir a qualidade do código?
Focar em funcionalidades críticas e garantir testes básicos, planejando refatorações futuras.
Explique a arquitetura do framework [X] que você usou em projetos anteriores.
Como você otimizaria o desempenho de uma aplicação usando [Y] framework?
Lock Pessimista
