50 System Design

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 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

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.

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

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

 

SAP RESTfull integration

Prompt

Tenho uma aplicação Spring Boot e preciso integrar com SAP, para envio de Produtos e Estoque, que será atualizado no WMS do SAP.
Identifique as etapas, no SAP para disponibilizar uma API RESTful, com segurança e que atenda o conceito de CRUD para entidade Product.
Identifique as etapas na aplicação Spring Boot, para autenticar na API do SAP e enviar um POST para criação de um novo Product.

Enhanced Prompt

“Desenvolva uma integração entre uma aplicação Spring Boot e o SAP para envio de dados de Produtos e Estoque, que serão atualizados no WMS do SAP. Para isso:

  1. No SAP: a. Identifique as etapas necessárias para criar uma API RESTful segura que atenda ao conceito de CRUD (Create, Read, Update, Delete) para a entidade Product. b. Especifique as configurações de segurança necessárias para a API, incluindo autenticação e autorização. c. Detalhe como configurar e implementar a API no SAP, considerando as melhores práticas de segurança e performance.

  2. Na aplicação Spring Boot: a. Descreva as etapas para autenticar na API RESTful do SAP, utilizando um mecanismo de autenticação adequado (por exemplo, OAuth, Basic Auth, etc.). b. Implemente um exemplo de código que demonstre como enviar uma requisição POST para a API do SAP para criar um novo Product, incluindo:

    • Configuração do cliente HTTP (por exemplo, RestTemplate ou WebClient).
    • Preparação dos dados de Product a serem enviados.
    • Tratamento de erros e exceções.
  3. Considere:

    • A API do SAP deve ser configurada para utilizar um protocolo de comunicação seguro (HTTPS).
    • A aplicação Spring Boot deve lidar com possíveis erros de comunicação, como timeouts e respostas de erro do SAP.
    • A implementação deve seguir as melhores práticas de segurança e coding standards tanto no SAP quanto na aplicação Spring Boot.

Forneça detalhes técnicos e exemplos de código quando aplicável, e mantenha a explicação clara e concisa.”

Abacus (Claude Sonnet 4.6)

Integração Spring Boot ↔ SAP (WMS) via API RESTful


🔷 Parte 1 — SAP: Disponibilizando uma API RESTful para Product

1. Pré-requisitos no SAP

  • SAP S/4HANA ou SAP ECC com SAP Gateway instalado
  • Módulo WM/EWM ativo para gestão de estoque/WMS
  • Acesso ao SAP Business Technology Platform (BTP) (opcional, mas recomendado para APIs modernas)

2. Criar o OData Service (API RESTful no SAP)

O SAP expõe APIs via OData (protocolo REST-like), usando o SAP Gateway Framework.

Passo a passo no SAP GUI:

a) Criar o projeto no SAP Gateway

Transação: SEGW (SAP Gateway Service Builder)
→ Criar novo projeto: ZWM_PRODUCT_SRV
→ Definir Entity Type: Product
   - ProductID (Key, String)
   - Description (String)
   - Quantity (Decimal)
   - UnitOfMeasure (String)
   - StorageLocation (String)
→ Definir Entity Set: ProductSet
→ Gerar CRUD: Create, Read, Update, Delete, Query

b) Implementar os métodos CRUD na classe de dados

Transação: SEGW → Reimplementar métodos:
- CREATE_ENTITY  → Cria produto no WMS
- GET_ENTITY     → Busca produto por ID
- GET_ENTITYSET  → Lista todos os produtos
- UPDATE_ENTITY  → Atualiza produto
- DELETE_ENTITY  → Remove produto

c) Ativar e publicar o serviço

Transação: /IWFND/MAINT_SERVICE
→ Add Service → buscar ZWM_PRODUCT_SRV
→ Ativar o serviço
→ URL gerada: https://<sap-host>:<port>/sap/opu/odata/sap/ZWM_PRODUCT_SRV/

3. Segurança na API SAP

a) Autenticação — OAuth 2.0 (recomendado)

SAP BTP → Security → OAuth 2.0 Configuration
→ Criar OAuth Client:
   - Client ID: spring_wms_client
   - Grant Type: Client Credentials
   - Scope: ZWM_PRODUCT_SRV
→ Token URL: https://<btp-host>/oauth/token

b) Autenticação — Basic Auth (alternativa simples)

Transação: SU01
→ Criar usuário técnico: WMS_API_USER
→ Tipo: System (S)
→ Atribuir perfil: Z_WMS_API_PROFILE

c) Autorização — Perfis e Roles

Transação: PFCG
→ Criar Role: Z_WMS_API_ROLE
→ Atribuir objeto de autorização: S_SERVICE
   - SRV_NAME: ZWM_PRODUCT_SRV
   - SRV_TYPE: HT (HTTP Service)
→ Gerar e atribuir ao usuário técnico

d) HTTPS / SSL

Transação: STRUST
→ Importar certificado SSL
→ Ativar HTTPS no ICM (Internet Communication Manager)
Transação: SMICM → HTTPS ativo na porta 443

4. Testar a API no SAP

Transação: /IWFND/GW_CLIENT
→ GET /ProductSet          → lista produtos
→ GET /ProductSet('P001')  → busca por ID
→ POST /ProductSet         → cria produto
→ PUT /ProductSet('P001')  → atualiza
→ DELETE /ProductSet('P001') → remove

🔶 Parte 2 — Spring Boot: Autenticar e enviar POST para SAP

1. Dependências — pom.xml

<dependencies>
    <!-- HTTP Client -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-webflux</artifactId>
    </dependency>
    <!-- OAuth2 Client -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-oauth2-client</artifactId>
    </dependency>
    <!-- Lombok -->
    <dependency>
        <groupId>org.projectlombok</groupId>
        <artifactId>lombok</artifactId>
    </dependency>
</dependencies>

2. Configuração — application.yml

sap:
  base-url: https://<sap-host>/sap/opu/odata/sap/ZWM_PRODUCT_SRV
  oauth:
    token-url: https://<btp-host>/oauth/token
    client-id: spring_wms_client
    client-secret: your-secret
    scope: ZWM_PRODUCT_SRV
  # Alternativa Basic Auth:
  basic:
    username: WMS_API_USER
    password: your-password

3. Model — ProductRequest.java

@Data
@Builder
public class ProductRequest {
    private String productID;
    private String description;
    private BigDecimal quantity;
    private String unitOfMeasure;
    private String storageLocation;
}

4. Serviço OAuth2 — SapAuthService.java

@Service
@RequiredArgsConstructor
public class SapAuthService {

    @Value("${sap.oauth.token-url}")
    private String tokenUrl;

    @Value("${sap.oauth.client-id}")
    private String clientId;

    @Value("${sap.oauth.client-secret}")
    private String clientSecret;

    @Value("${sap.oauth.scope}")
    private String scope;

    private final WebClient webClient = WebClient.create();

    public String getAccessToken() {
        return webClient.post()
            .uri(tokenUrl)
            .contentType(MediaType.APPLICATION_FORM_URLENCODED)
            .body(BodyInserters.fromFormData("grant_type", "client_credentials")
                .with("client_id", clientId)
                .with("client_secret", clientSecret)
                .with("scope", scope))
            .retrieve()
            .bodyToMono(JsonNode.class)
            .map(json -> json.get("access_token").asText())
            .block();
    }
}

5. Serviço de Integração — SapProductService.java

@Service
@RequiredArgsConstructor
@Slf4j
public class SapProductService {

    @Value("${sap.base-url}")
    private String sapBaseUrl;

    private final SapAuthService authService;
    private final WebClient.Builder webClientBuilder;

    public void createProduct(ProductRequest product) {
        String token = authService.getAccessToken();

        WebClient client = webClientBuilder
            .baseUrl(sapBaseUrl)
            .defaultHeader(HttpHeaders.AUTHORIZATION, "Bearer " + token)
            .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
            .defaultHeader("Accept", "application/json")
            .build();

        // OData requer X-CSRF-Token — buscar antes do POST
        String csrfToken = fetchCsrfToken(client);

        client.post()
            .uri("/ProductSet")
            .header("X-CSRF-Token", csrfToken)
            .bodyValue(product)
            .retrieve()
            .onStatus(HttpStatusCode::isError, response ->
                response.bodyToMono(String.class)
                    .flatMap(body -> Mono.error(
                        new RuntimeException("SAP API Error: " + body))))
            .bodyToMono(Void.class)
            .doOnSuccess(v -> log.info("Product {} created in SAP WMS", product.getProductID()))
            .block();
    }

    // OData exige CSRF Token para operações de escrita (POST/PUT/DELETE)
    private String fetchCsrfToken(WebClient client) {
        return client.get()
            .uri("/ProductSet?$top=1")
            .header("X-CSRF-Token", "Fetch")
            .retrieve()
            .toBodilessEntity()
            .map(response -> response.getHeaders()
                .getFirst("X-CSRF-Token"))
            .block();
    }
}

6. Controller — ProductController.java

@RestController
@RequestMapping("/api/products")
@RequiredArgsConstructor
public class ProductController {

    private final SapProductService sapProductService;

    @PostMapping
    public ResponseEntity<String> createProduct(@RequestBody @Valid ProductRequest request) {
        sapProductService.createProduct(request);
        return ResponseEntity.status(HttpStatus.CREATED)
            .body("Product sent to SAP WMS successfully");
    }
}

🔑 Pontos de Atenção

Tópico Detalhe
X-CSRF-Token Obrigatório em toda escrita OData SAP — sempre buscar antes do POST
OAuth vs Basic OAuth 2.0 é recomendado para produção; Basic Auth apenas para dev/teste
OData vs REST puro SAP Gateway usa OData; para REST puro considere SAP Integration Suite
SAP BTP Ideal para expor APIs modernas com segurança gerenciada
Certificado SSL Em produção, configurar SSLContext no WebClient com o certificado SAP
Retry/Circuit Breaker Adicionar Resilience4j para tolerância a falhas na integração

Adapta

Visão geral

Abaixo está um guia técnico completo para integrar uma aplicação Spring Boot com o SAP para envio de dados de Produto (e, por extensão, Estoque), visando atualização no WMS do SAP. O foco recai em:

  • Expor no SAP uma API RESTful (tipicamente OData) segura, com CRUD para Product.
  • Consumir essa API a partir do Spring Boot com boas práticas de segurança, robustez e performance.
  • Exemplos práticos de configuração e código.

Observação importante: quando possível, avalie usar uma API padrão do SAP (ex.: Product Master) em vez de construir uma API customizada. Se não houver API padrão que atenda, use RAP (ABAP RESTful Application Programming Model) para criar uma API customizada OData V4. Os passos abaixo contemplam ambos os cenários.


1) No SAP

1.a) Etapas para criar uma API RESTful CRUD (entidade Product)

Existem duas abordagens principais:

  1. Usar API padrão (recomendado quando existir)
  • Exemplo: S/4HANA tem a API “Product Master” (serviço OData v2), com entidade A_Product, que já provê leitura e, em alguns cenários, criação/atualização dependendo da edição do S/4HANA e autorização.
  • Passos:
    • Ativar/checar o serviço no SAP Gateway (on‑prem: transação /IWFND/MAINT_SERVICE; cloud: Communication Arrangement).
    • Publicar o endpoint e garantir que o canal HTTPS esteja ativo.
    • Criar usuários de comunicação (Cloud) ou usuários técnicos (on‑prem), papéis e perfis autorizativos.
    • Configurar autenticação (OAuth 2.0 Client Credentials em Cloud; Basic/OAuth em on‑prem) e escopos.
    • Testar via SAP API Hub ou via o próprio endpoint OData.
  1. Criar API customizada com ABAP RAP (OData V4)
  • Passos no ADT (ABAP Development Tools no Eclipse):
    1. Modelagem de Dados (CDS):
      • Criar CDS View Entity Z_I_Product com chaves e campos de negócio (ProductId, SKU, Name, Description, Unit, Price, WarehouseId etc.).
      • Definir anotação @AccessControl para controle de acesso (se usar DCL).
    2. Comportamento (Behavior Definition/Implementation):
      • Criar Behavior Definition (BDEF) para habilitar create, update, delete e read.
      • Implementar Behavior Implementation (classe ABAP) para regras de negócio, validações e persistência.
    3. Service Definition:
      • Definir a Service Definition incluindo a entidade Product (ex.: expose Z_I_Product as Products).
    4. Service Binding:
      • Criar Service Binding (OData V4 UI/Service). Publicar o serviço e capturar o caminho do endpoint.
    5. Ativação e Testes:
      • Ativar objetos, usar o preview do ADT para inspecionar a $metadata e testar operações CRUD.
    6. Segurança e Autorização:
      • Definir objetos de autorização (PFCG) e perfis.
      • Amarrar escopos/roles à exposição do serviço (IAM em Cloud; PFCG/roles em on‑prem).
    7. Gateway/ICF:
      • Garantir que o serviço está acessível via ICF (SICF) e que HTTPS está ativo (STRUST/ICM).

Dica: Se o WMS estiver em SAP EWM e você realmente precisa atualizar estoques, verifique APIs padrão de estoque/warehouse tasks. Caso não cubram o fluxo, crie também uma entidade de “Inventory/Stock” via RAP ou componha via API Management.

1.b) Configurações de segurança (autenticação e autorização)

  • Protocolo:
    • Somente HTTPS (TLS 1.2+). Desabilite cifras fracas. Em on‑prem, configure em STRUST/ICM. Em Cloud, por padrão é HTTPS.
  • Autenticação:
    • SAP S/4HANA Cloud e BTP: preferencialmente OAuth 2.0 Client Credentials (máquina‑para‑máquina).
    • On‑prem (Gateway): pode-se usar Basic Auth sobre HTTPS ou OAuth 2.0 via SAP Identity Authentication/IdP.
  • Autorização:
    • Definir roles e escopos: “Product.Read”, “Product.Write”, “Product.Delete” etc.
    • Atribuir papéis a usuários técnicos (on‑prem) ou a “Communication Users/Arrangements” (Cloud).
  • CSRF:
    • Para operações de escrita (POST/PUT/PATCH/DELETE) em OData, use X-CSRF-Token.
    • Fluxo: primeiro requisitar token com header X-CSRF-Token: Fetch; depois enviar a mutação com header X-CSRF-Token: e o cookie de sessão retornado.
  • Proteções adicionais:
    • Rate limiting e quotas via SAP API Management (se expor pela camada de API).
    • IP allowlist.
    • Logging/auditoria e mascaramento de dados sensíveis.
    • CORS conforme necessário (se front-ends externos consumirem a API).
    • Conteúdo: aceite e responda application/json; rejeite formatos inesperados.

1.c) Configurar e implementar a API no SAP com segurança e performance

  • Performance (RAP/OData):
    • Use $select para reduzir colunas devolvidas.
    • Paginação ($top/$skip).
    • ETags e If-Match para controle concorrente e caching.
    • $batch para operações em lote quando precisar criar/atualizar muitos registros.
    • Pushdown no banco: CDS, AMDP quando necessário, índices nas tabelas.
    • GZIP habilitado no ICM (compressão HTTP).
  • Hardening:
    • Validar payloads no Behavior Implementation (tamanhos máximos, formatos, ranges).
    • Sanitizar entradas (evitar injeções em consultas dinâmicas).
    • Separar usuários de leitura e escrita (princípio do menor privilégio).
  • Observabilidade:
    • Ativar logs de acesso/erros no ICM/Gateway.
    • Correlação: suportar cabeçalho X-Correlation-Id (propagar a partir do cliente).
  • Publicação do endpoint:
    • Exemplo genérico de endpoint OData V4 (RAP):
      • GET/POST: https:///sap/opu/odata4////Products
      • PATCH/DELETE/GET por chave: https:///…/Products(”)
    • OData V2 (API padrão, ex. Product Master):
      • GET/POST: https:///sap/opu/odata/sap/API_PRODUCT_SRV/A_Product

Links úteis:


2) Na aplicação Spring Boot

2.a) Etapas para autenticar na API do SAP

Escolha 1: OAuth 2.0 Client Credentials (recomendado em Cloud/BTP/S/4HANA Cloud ou via API Management)

  • Fluxo:
    • Obter access_token no token endpoint (client_id, client_secret).
    • Incluir Authorization: Bearer em todas as chamadas à API.
  • Benefícios: rotação de segredos, escopos, revogação centralizada.

Escolha 2: Basic Auth (possível em on‑prem)

  • Fluxo:
    • Enviar Authorization: Basic <base64(user:password)> sobre HTTPS.
  • Notas: Menos flexível; use contas técnicas com privilégios mínimos, segredo guardado em cofre.

CSRF (independente do método de autenticação):

  • Para POST/PUT/PATCH/DELETE em OData, requisitar token:
    • Enviar uma chamada preliminar (ex.: GET em $metadata ou HEAD) com X-CSRF-Token: Fetch.
    • Reutilizar o token X-CSRF-Token e o cookie de sessão (ex.: SAP_SESSIONID) na chamada de escrita.

TLS:

  • Importe o certificado do servidor SAP em um truststore (JKS/P12).
  • Configure o WebClient/HTTP client para confiar apenas no truststore (não desative validações!).

Timeouts, retries e resiliência:

  • Timeouts de conexão, leitura e escrita.
  • Retry com backoff para 429/503/504 (não retentar em 4xx de validação).
  • Circuit breaker e bulkhead se necessário.

2.b) Exemplo de código (Spring Boot) – POST para criar Product

A seguir, um exemplo com:

  • WebClient (preferido) com timeouts.
  • OAuth2 Client Credentials.
  • Fluxo de CSRF para OData.
  • Tratamento de erros com parsing do erro OData.
  • Alternativa com Basic Auth (comentada).

Estrutura minimalista:

  • application.yml
  • DTOs: ProductRequest, SapODataError
  • Configuração: WebClientConfig (inclui SSL, OAuth, timeouts)
  • Cliente: SapProductClient (getCsrfToken + createProduct)
  • Exemplo de uso no Service/Controller

application.yml (exemplo)

server:
  port: 8080

sap:
  base-url: "https://sap.example.com/sap/opu/odata4/zns/product/0001"
  product-path: "/Products"
  # Para OData v2 (API padrão), algo como:
  # base-url: "https://sap.example.com/sap/opu/odata/sap/API_PRODUCT_SRV"
  # product-path: "/A_Product"

security:
  oauth2:
    client:
      sap:
        token-uri: "https://sap-iam.example.com/oauth/token"
        client-id: "${SAP_CLIENT_ID}"
        client-secret: "${SAP_CLIENT_SECRET}"
        scope: "Product.Write"

http:
  connect-timeout-ms: 5000
  read-timeout-ms: 10000
  write-timeout-ms: 10000

ssl:
  enabled: true
  truststore:
    path: "classpath:truststore/sap-truststore.p12"
    password: "${TRUSTSTORE_PASSWORD}"
    type: "PKCS12"

Coloque os segredos (client-secret, senhas) em variáveis de ambiente/cofre.

DTOs

// Produto enviado para criação no SAP (ajuste campos aos do serviço SAP real)
public record ProductRequest(
    String ProductId,
    String SKU,
    String Name,
    String Description,
    String Unit,
    String WarehouseId,
    java.math.BigDecimal Price,
    java.time.OffsetDateTime LastUpdated
) {}

// Erro OData típico (simplificado)
public class SapODataError {
  public Error error;
  public static class Error {
    public String code;
    public Message message;
  }
  public static class Message {
    public String lang;
    public String value;
  }
}

Observação: No serviço padrão API_PRODUCT_SRV (OData v2), o payload e campos são diferentes (ex.: Product, ProductType, BaseUnit, ProductGroup etc.). Adeque o DTO aos metadados ($metadata) do seu endpoint.

Configurando WebClient com OAuth2, SSL e timeouts

import io.netty.handler.ssl.SslContextBuilder;
import io.netty.handler.ssl.util.InsecureTrustManagerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.client.reactive.ReactorClientHttpConnector;
import org.springframework.util.StringUtils;
import org.springframework.web.reactive.function.client.ExchangeFilterFunction;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.netty.http.client.HttpClient;
import reactor.netty.tcp.TcpClient;

import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.TrustManagerFactory;
import java.io.InputStream;
import java.security.KeyStore;
import java.time.Duration;
import java.util.Map;

@Configuration
public class WebClientConfig {

  @Value("${sap.base-url}")
  private String sapBaseUrl;

  @Value("${http.connect-timeout-ms:5000}")
  private int connectTimeoutMs;

  @Value("${http.read-timeout-ms:10000}")
  private int readTimeoutMs;

  @Value("${http.write-timeout-ms:10000}")
  private int writeTimeoutMs;

  @Value("${ssl.enabled:true}")
  private boolean sslEnabled;

  @Value("${ssl.truststore.path:}")
  private String truststorePath;

  @Value("${ssl.truststore.password:}")
  private String truststorePassword;

  @Value("${ssl.truststore.type:PKCS12}")
  private String truststoreType;

  @Bean
  public WebClient sapWebClient(WebClient.Builder builder) throws Exception {
    HttpClient httpClient = HttpClient.create()
        .responseTimeout(Duration.ofMillis(readTimeoutMs));

    if (sslEnabled) {
      httpClient = httpClient.secure(sslContextSpec -> {
        try {
          if (StringUtils.hasText(truststorePath)) {
            KeyStore ts = KeyStore.getInstance(truststoreType);
            try (InputStream is = getClass().getResourceAsStream(truststorePath.startsWith("classpath:") ?
                truststorePath.replace("classpath:", "/") : truststorePath)) {
              ts.load(is, truststorePassword.toCharArray());
            }
            TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
            tmf.init(ts);
            sslContextSpec.sslContext(SslContextBuilder.forClient().trustManager(tmf).build());
          } else {
            // Evite isto em produção; aqui só como fallback ilustrativo
            sslContextSpec.sslContext(SslContextBuilder.forClient()
                .trustManager(InsecureTrustManagerFactory.INSTANCE).build());
          }
        } catch (Exception e) {
          throw new RuntimeException("Erro configurando SSL", e);
        }
      });
    }

    return builder
        .baseUrl(sapBaseUrl)
        .clientConnector(new ReactorClientHttpConnector(httpClient))
        .defaultHeader("Accept", "application/json")
        .filter(loggingFilter())
        .build();
  }

  private ExchangeFilterFunction loggingFilter() {
    return ExchangeFilterFunction.ofRequestProcessor(clientRequest -> {
      // Log enxuto, sem segredos
      System.out.println("SAP Request: " + clientRequest.method() + " " + clientRequest.url());
      return reactor.core.publisher.Mono.just(clientRequest);
    });
  }
}

Autenticação OAuth2: podemos obter o token com um pequeno TokenClient e aplicar um ExchangeFilterFunction para adicionar o header Authorization.

import org.springframework.beans.factory.annotation.Value;
import org.springframework.http.MediaType;
import org.springframework.stereotype.Component;
import org.springframework.web.reactive.function.client.WebClient;

import java.time.Instant;
import java.util.Map;

@Component
public class OAuthTokenClient {

  private final WebClient http;
  private final String tokenUri;
  private final String clientId;
  private final String clientSecret;
  private final String scope;

  private volatile String cachedToken;
  private volatile Instant expiresAt = Instant.EPOCH;

  public OAuthTokenClient(
      WebClient.Builder builder,
      @Value("${security.oauth2.client.sap.token-uri}") String tokenUri,
      @Value("${security.oauth2.client.sap.client-id}") String clientId,
      @Value("${security.oauth2.client.sap.client-secret}") String clientSecret,
      @Value("${security.oauth2.client.sap.scope:}") String scope
  ) {
    this.http = builder.baseUrl(tokenUri).build();
    this.tokenUri = tokenUri;
    this.clientId = clientId;
    this.clientSecret = clientSecret;
    this.scope = scope;
  }

  public synchronized String getAccessToken() {
    if (cachedToken != null && Instant.now().isBefore(expiresAt.minusSeconds(30))) {
      return cachedToken;
    }
    var bodySpec = http.post()
        .contentType(MediaType.APPLICATION_FORM_URLENCODED)
        .bodyValue("grant_type=client_credentials&client_id=" + clientId +
            "&client_secret=" + clientSecret +
            (scope != null && !scope.isBlank() ? "&scope=" + scope : ""));

    Map<?, ?> token = bodySpec.retrieve()
        .bodyToMono(Map.class)
        .block();

    String accessToken = (String) token.get("access_token");
    Number expiresIn = (Number) token.get("expires_in");
    cachedToken = accessToken;
    expiresAt = Instant.now().plusSeconds(expiresIn != null ? expiresIn.longValue() : 300);
    return cachedToken;
  }
}

Filter para aplicar o Bearer Token:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.reactive.function.client.ExchangeFilterFunction;

@Configuration
public class OAuthFilterConfig {

  @Bean
  public ExchangeFilterFunction oauthBearerFilter(OAuthTokenClient tokenClient) {
    return ExchangeFilterFunction.ofRequestProcessor(req -> {
      return reactor.core.publisher.Mono.just(
          ClientRequest.from(req)
              .headers(h -> h.setBearerAuth(tokenClient.getAccessToken()))
              .build()
      );
    });
  }
}

E injete esse filtro no WebClient (no bean sapWebClient), por exemplo:

// dentro de sapWebClient(...)
return builder
    .baseUrl(sapBaseUrl)
    .clientConnector(new ReactorClientHttpConnector(httpClient))
    .defaultHeader("Accept", "application/json")
    .filter(oauthBearerFilter) // injete esse bean aqui
    .filter(loggingFilter())
    .build();

Alternativa Basic Auth (se optar):

  • Em vez do filter acima, use .defaultHeaders(h -> h.setBasicAuth(user, password)) no WebClient.

Cliente para SAP: obtendo CSRF e criando Product

import org.springframework.beans.factory.annotation.Value;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.http.ResponseCookie;
import org.springframework.stereotype.Component;
import org.springframework.web.reactive.function.BodyInserters;
import org.springframework.web.reactive.function.client.ClientResponse;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.core.publisher.Mono;

import java.net.HttpCookie;
import java.util.List;
import java.util.Map;
import java.util.Optional;

@Component
public class SapProductClient {

  private final WebClient sapWebClient;
  private final String productPath;

  public SapProductClient(
      WebClient sapWebClient,
      @Value("${sap.product-path}") String productPath
  ) {
    this.sapWebClient = sapWebClient;
    this.productPath = productPath;
  }

  // 1) Obter X-CSRF-Token e cookies de sessão
  public CsrfSession fetchCsrf() {
    ClientResponse resp = sapWebClient.get()
        .uri(uriBuilder -> uriBuilder
            // Para OData V4: chamar $metadata ou a entidade com $top=1
            .path("/$metadata")
            .build()
        )
        .header("X-CSRF-Token", "Fetch")
        .exchangeToMono(Mono::just)
        .block();

    if (resp == null) {
      throw new RuntimeException("Sem resposta do SAP ao requisitar CSRF");
    }

    String token = resp.headers().asHttpHeaders().getFirst("X-CSRF-Token");
    List<String> setCookies = resp.headers().asHttpHeaders().getOrDefault(HttpHeaders.SET_COOKIE, List.of());
    if (token == null || setCookies.isEmpty()) {
      // Alguns endpoints retornam o token apenas em mutação; em OData geralmente funciona no $metadata
      throw new RuntimeException("Não foi possível obter CSRF Token e/ou cookies de sessão do SAP");
    }

    // Coletar cookies para reenviar
    String cookieHeader = String.join("; ",
        setCookies.stream()
            .map(ResponseCookie::fromClientResponse)
            .map(Object::toString)
            .toList()
    );

    return new CsrfSession(token, cookieHeader);
  }

  // 2) Criar Product (POST)
  public Map<?, ?> createProduct(ProductRequest product) {
    CsrfSession csrf = fetchCsrf();

    ClientResponse resp = sapWebClient.post()
        .uri(productPath) // ex.: "/Products" ou "/A_Product"
        .contentType(MediaType.APPLICATION_JSON)
        .header("X-CSRF-Token", csrf.token())
        .header(HttpHeaders.COOKIE, csrf.cookieHeader())
        .header("X-Correlation-Id", Correlation.id()) // se você usa correlação
        .body(BodyInserters.fromValue(product))
        .exchangeToMono(Mono::just)
        .block();

    if (resp == null) {
      throw new RuntimeException("Sem resposta do SAP ao criar Product");
    }

    if (resp.statusCode().is2xxSuccessful()) {
      return resp.bodyToMono(Map.class).block();
    }

    // Tratamento de erro OData
    String raw = resp.bodyToMono(String.class).block();
    SapODataError err = null;
    try {
      err = JsonUtils.fromJson(raw, SapODataError.class); // implemente um util com Jackson
    } catch (Exception ignore) {}

    String msg = Optional.ofNullable(err)
        .map(e -> e.error != null && e.error.message != null ? e.error.message.value : null)
        .orElse(raw);

    if (resp.statusCode().value() == 409) {
      throw new ConflictException("Conflito ao criar Product: " + msg);
    } else if (resp.statusCode().is4xxClientError()) {
      throw new ClientErrorException("Erro 4xx do SAP: " + msg);
    } else if (resp.statusCode().is5xxServerError()) {
      throw new ServerErrorException("Erro 5xx do SAP: " + msg);
    } else {
      throw new RuntimeException("Erro inesperado do SAP (" + resp.statusCode().value() + "): " + msg);
    }
  }

  public record CsrfSession(String token, String cookieHeader) {}
}

Utilitário simples para JSON (Jackson):

import com.fasterxml.jackson.databind.ObjectMapper;

public class JsonUtils {
  private static final ObjectMapper MAPPER = new ObjectMapper();
  public static <T> T fromJson(String json, Class<T> type) {
    try {
      return MAPPER.readValue(json, type);
    } catch (Exception e) {
      throw new RuntimeException("Falha ao parsear JSON", e);
    }
  }
}

Correlation ID (opcional):

import java.util.UUID;

public class Correlation {
  private static final ThreadLocal<String> ID = new ThreadLocal<>();

  public static String id() {
    String v = ID.get();
    if (v == null) {
      v = UUID.randomUUID().toString();
      ID.set(v);
    }
    return v;
  }

  public static void clear() {
    ID.remove();
  }
}

Exemplo de uso em um Service/Controller:

import org.springframework.stereotype.Service;

@Service
public class ProductService {

  private final SapProductClient sapProductClient;

  public ProductService(SapProductClient sapProductClient) {
    this.sapProductClient = sapProductClient;
  }

  public Map<?, ?> createProduct(ProductRequest req) {
    // Validações locais
    if (req.ProductId() == null || req.ProductId().isBlank()) {
      throw new IllegalArgumentException("ProductId é obrigatório");
    }
    // Idempotência (opcional): consultar antes; ou usar chave natural como ProductId
    return sapProductClient.createProduct(req);
  }
}

Tratamento de timeouts e retries:

  • Você pode envolver as chamadas com Resilience4j:
<!-- pom.xml -->
<dependency>
  <groupId>io.github.resilience4j</groupId>
  <artifactId>resilience4j-spring-boot3</artifactId>
  <version>2.2.0</version>
</dependency>
// Exemplo: retry apenas para 503/504/429
import io.github.resilience4j.retry.annotation.Retry;
import org.springframework.web.reactive.function.client.WebClientResponseException;

@Retry(name = "sapCreateProduct")
public Map<?, ?> createProductWithRetry(ProductRequest req) {
  try {
    return sapProductClient.createProduct(req);
  } catch (WebClientResponseException.TooManyRequests |
           WebClientResponseException.ServiceUnavailable |
           WebClientResponseException.GatewayTimeout e) {
    throw e; // Retentável
  } catch (Exception e) {
    throw e; // Não retentar por padrão
  }
}

application.yml (Resilience4j):

resilience4j:
  retry:
    instances:
      sapCreateProduct:
        max-attempts: 3
        wait-duration: 1s
        retry-exceptions:
          - org.springframework.web.reactive.function.client.WebClientResponseException$TooManyRequests
          - org.springframework.web.reactive.function.client.WebClientResponseException$ServiceUnavailable
          - org.springframework.web.reactive.function.client.WebClientResponseException$GatewayTimeout

Observações sobre OData e CSRF:

  • Alguns proxies/API Management podem gerenciar CSRF; caso o endpoint finalize a necessidade do token, remova a etapa de fetch. Em geral, serviços OData no SAP exigem X-CSRF-Token para métodos mutáveis.
  • Para OData v2, o caminho do metadata é /$metadata sob o serviço; para v4 (RAP) também.

Alternativa com RestTemplate (se preferir, embora seja legado):

RestTemplate rest = new RestTemplateBuilder()
    .setConnectTimeout(Duration.ofMillis(5000))
    .setReadTimeout(Duration.ofMillis(10000))
    .build();
// Obtenha CSRF via exchange() e reenvie cookies + header nas mutações

3) Considerações e melhores práticas

  • HTTPS obrigatório:
    • Verifique o handshake TLS e a cadeia de certificação em homologação antes da produção.
  • Padrão de payloads e tipos:
    • Use application/json; verifique se o serviço aceita e retorna JSON (OData v2/v4 normalmente suportam).
  • Tratamento de erro do SAP:
    • OData retorna um envelope com “error.code” e “error.message.value”.
    • Mapeie 400/404/409, 5xx. Não retentar 4xx de validação.
  • Idempotência:
    • Para criação, considere:
      • Usar chave natural (ProductId) e tratar 409 (conflito) como já criado.
      • Ou usar um header de idempotência (se exposto via API Management) com deduplicação no SAP.
  • Concorrência:
    • Utilize ETag/If-Match em updates (PATCH) para evitar sobregravações.
  • Performance no cliente:
    • Conexões persistentes (HTTP/1.1 keep-alive ou HTTP/2, se suportado).
    • GZIP habilitado.
    • Batch ($batch) para grandes volumes.
  • Observabilidade:
    • Logue o X-Correlation-Id em ambos os lados para rastrear fluxos.
    • Métricas e alertas (latência, taxa de erro, timeouts).
  • Segurança de segredos:
    • Nunca comitar segredos. Use Vault/Secrets Manager/KMS.
    • Rotacione credenciais periodicamente.
  • Padrões de código:
    • DTOs imutáveis, validações com Bean Validation.
    • Camadas separadas (Controller/Service/Client).
    • Testes integrados contra sandbox/API Hub quando disponível.

Exemplos de chamadas CRUD (genéricos)

Supondo RAP OData V4, base-url: https://sap.example.com/sap/opu/odata4/zns/product/0001

  • Create (POST):
    • POST /Products
    • Headers: Authorization: Bearer , X-CSRF-Token: , Cookie: <sessão>, Content-Type: application/json
    • Body (exemplo adaptado ao seu metadado): { “ProductId”: “PRD-001”, “SKU”: “SKU-001”, “Name”: “Produto X”, “Description”: “Descrição”, “Unit”: “EA”, “WarehouseId”: “WH01”, “Price”: 99.90, “LastUpdated”: “2026-02-20T10:00:00Z” }
  • Read (GET):
    • GET /Products(‘PRD-001’)?$select=ProductId,Name,SKU
    • GET /Products?$filter=WarehouseId eq ‘WH01’&$top=50&$skip=0
  • Update (PATCH):
    • PATCH /Products(‘PRD-001’)
    • Headers: X-CSRF-Token, If-Match:
    • Body: { “Price”: 109.90 }
  • Delete (DELETE):
    • DELETE /Products(‘PRD-001’)
    • Headers: X-CSRF-Token, If-Match:

Para OData V2 (API_PRODUCT_SRV), adapte endpoints e nomes de campos conforme a $metadata.


Estoque (WMS) – Nota rápida

  • Se você também precisa atualizar o estoque, verifique se há API padrão do EWM (por exemplo, para Quantidades, Warehouse Tasks, Stock Change). Caso contrário, crie um serviço RAP para uma entidade Inventory/Stock (chaves como ProductId + WarehouseId + StorageBin etc.), com as mesmas diretrizes de segurança e performance.
  • Consistência entre Produto e Estoque:
    • Se forem dois endpoints, trate a consistência via “saga” (compensações) ou use $batch transacional se o serviço suportar.
    • Idempotência é crítica para eventos de estoque (evitar contagens duplicadas).

Checklist rápido

  • SAP
    • Usar API padrão (ex.: Product Master) OU publicar RAP OData V4 para Product/Inventory.
    • Habilitar HTTPS com TLS 1.2+ e cifras fortes.
    • Configurar autenticação (OAuth 2.0 Client Credentials preferencial).
    • Definir roles/escopos e autorização por operação.
    • Habilitar/usar X-CSRF-Token para métodos mutáveis.
    • Performance: $select/$filter/paginação/$batch/GZIP, ETags.
    • Logs/auditoria, correlacionar requisições.
  • Spring Boot
    • WebClient com timeouts, TLS truststore configurado.
    • OAuth2 Token Client ou Basic Auth.
    • Fluxo CSRF: fetch + reuso de token e cookies.
    • Tratamento de erros OData (parse de “error.message.value”).
    • Retries com backoff para 429/503/504; não retentar 4xx de validação.
    • Observabilidade, correlação, segurança de segredos.

Conclusão

  • No SAP, prefira APIs padrão. Se não houver, crie um serviço OData V4 com RAP, com CRUD completo para Product, segurança via OAuth 2.0, HTTPS, CSRF, roles/escopos, e boas práticas de performance (ETags, $select, paginação).
  • No Spring Boot, use WebClient com OAuth2 Client Credentials, configure SSL com truststore, implemente o fluxo de CSRF, trate erros OData adequadamente, aplique timeouts/retries com backoff e mantenha logs e correlações.
  • Para Estoque/WMS, avalie APIs padrão do EWM; na ausência, modele e exponha uma entidade Inventory/Stock com os mesmos padrões.

Se quiser, posso:

  • Validar a $metadata do seu endpoint para ajustar exatamente o DTO e os campos.
  • Fornecer um exemplo usando a API padrão API_PRODUCT_SRV com campos reais.
  • Montar um fluxo $batch para criação em massa com idempotência.

DotNet WhenAll LoadAsync

Prompt

Como evitar task.whenall com multiplos loadasync, utilizado com DbContext?

Google Modo IA

Para o Entity Framework Core, o uso de Task.WhenAll com o mesmo DbContext resultará no erro: “A second operation started on this context before a previous operation completed”. Isso ocorre porque o DbContext não é thread-safe e não suporta operações paralelas simultâneas na mesma instância.
Para resolver isso e evitar o Task.WhenAll problemático, você tem três caminhos principais:
1. Utilize IDbContextFactory (Recomendado para Paralelismo)
Se você precisa carregar dados em paralelo para ganhar performance, a solução oficial é injetar o IDbContextFactory. Isso permite criar uma instância isolada do contexto para cada tarefa.
csharp
// No construtor: private readonly IDbContextFactory<MyDbContext> _contextFactory;

public async Task LoadDataInParallel()
{
    var task1 = Task.Run(async () => {
        using var context = _contextFactory.CreateDbContext();
        return await context.Users.ToListAsync();
    });

    var task2 = Task.Run(async () => {
        using var context = _contextFactory.CreateDbContext();
        return await context.Orders.ToListAsync();
    });

    await Task.WhenAll(task1, task2); // Agora é seguro pois cada Task tem seu próprio Context
}
Use o código com cuidado.

2. Execução Sequencial (Simples e Segura)
Se a performance de carregar tudo ao mesmo tempo não for crítica, a forma mais segura de evitar o erro é simplesmente aguardar cada chamada individualmente. Isso garante que apenas uma operação utilize a conexão por vez.
csharp
var users = await _context.Users.ToListAsync();
var orders = await _context.Orders.ToListAsync(); // Só inicia após o término da anterior
Use o código com cuidado.

3. Projeção Única (Query Splitting ou Joins)
Em vez de múltiplos LoadAsync, tente consolidar as buscas em uma única consulta ao banco ou utilize o AsSplitQuery() se o problema for o carregamento de muitas coleções relacionadas (Avoid Cartesian Explosion).
Resumo de quando usar cada um:
  • IDbContextFactory: Use quando o paralelismo é indispensável (ex: Dashboards complexos ou Blazor Server).
  • Await sequencial: Use em fluxos simples de CRUD onde a latência do banco é baixa.
  • Split Queries: Use se os múltiplos “loads” forem para carregar propriedades de navegação de uma mesma entidade.
Você está enfrentando esse problema em uma aplicação Web API comum ou em um cenário de Background Service/Blazor?

Prompt

Como evitar task.whenall com multiplos loadasync?

Google Modo IA

Para evitar o uso de Task.WhenAll ao lidar com múltiplos LoadAsync, você pode adotar diferentes padrões dependendo do seu objetivo (performance, controle de concorrência ou ordem de execução):
1. Processamento Conforme Conclusão (Task.WhenAny)
Se você não quer esperar todos terminarem para começar a processar os resultados, use o padrão de remover tarefas de uma lista conforme elas finalizam. Isso melhora a responsividade.
csharp
var tasks = new List<Task<Data>> { LoadAsync(1), LoadAsync(2), LoadAsync(3) };
while (tasks.Count > 0)
{
    var finishedTask = await Task.WhenAny(tasks);
    tasks.Remove(finishedTask);
    var data = await finishedTask; // Processa assim que cada um termina
}
Use o código com cuidado.

2. Controle de Concorrência (SemaphoreSlim)
Para evitar sobrecarregar o sistema com muitos LoadAsync simultâneos (o que o WhenAll faz por padrão), utilize um SemaphoreSlim para limitar quantas tarefas rodam ao mesmo tempo.
csharp
var semaphore = new SemaphoreSlim(3); // Limite de 3 simultâneos
var tasks = items.Select(async item => {
    await semaphore.WaitAsync();
    try { return await LoadAsync(item); }
    finally { semaphore.Release(); }
});
await Task.WhenAll(tasks); // Ainda usa WhenAll, mas com execução controlada
Use o código com cuidado.

3. Iteração Assíncrona Moderna (Parallel.ForEachAsync)
No .NET 6+, a melhor alternativa ao WhenAll para coleções é o Parallel.ForEachAsync. Ele gerencia automaticamente o grau de paralelismo e é mais eficiente para processar grandes volumes de dados.
csharp
await Parallel.ForEachAsync(items, async (item, token) => {
    await LoadAsync(item); // Execução paralela controlada nativamente
});
Use o código com cuidado.

4. Execução Sequencial (Simples await)
Se os carregamentos dependem um do outro ou se a ordem é crítica, abandone o paralelismo e use o await individual. Isso evita a complexidade de gerenciar múltiplas tarefas.
csharp
var res1 = await LoadAsync(1);
var res2 = await LoadAsync(2); // Só inicia após o primeiro terminar
Use o código com cuidado.

Qual é o cenário específico dos seus LoadAsync (ex: muitas chamadas de API, leitura de arquivos ou carregamento de UI)?

Análise código .Net

Consigo sim fazer essa avaliação — mas eu não consigo acessar diretamente um caminho local do seu Windows (C:\Users\...) a partir daqui. Para eu analisar o projeto de verdade (código, csproj, camadas, DbContext, queries, etc.), você tem 3 opções:

  1. Enviar um ZIP do repositório (ideal)
  2. Enviar somente partes relevantes (pasta de Data/Infra, DbContext, Repositories/Services, Controllers/Handlers, principais Entities e Migrations)
  3. Rodar análises automatizadas aí e me mandar os relatórios (Sonar/Analyzers/CodeMetrics), e eu interpreto e devolvo um parecer com recomendações

✅ Dica de privacidade: antes de enviar, remova/mascare secrets, connection strings, chaves, certificados e qualquer dado sensível (appsettings.* / user-secrets / pipelines).


O que eu vou entregar (quando você enviar o código ou os relatórios)

Um relatório estruturado com:

  • Misuse de Entity Framework (anti‑patterns + impacto: performance, concorrência, consistência, manutenção)
  • Violação de SOLID (por princípio, com exemplos e refatorações sugeridas)
  • Clean Code (legibilidade, complexidade, duplicação, acoplamento, testes, logs, exceptions)
  • Severidade e priorização: Quick wins (1–2 dias), Médio prazo (1–2 sprints), Estrutural (refatoração maior)
  • Trechos de código anotados (antes/depois) quando aplicável

Para começar: me diga 3 coisas rápidas

  1. O projeto usa EF Core ou EF6? (e versão do .NET: 6/7/8?)
  2. A arquitetura é Clean Architecture, DDD, N‑tier, CQRS/MediatR…?
  3. O problema percebido hoje é mais performance, bugs, dificuldade de evoluir, ou tudo isso?

Se você responder isso, eu já ajusto o foco da análise.


Checklist do que eu vou procurar (e como vou marcar “uso indevido”)

1) Entity Framework — Principais “misuses” / anti‑patterns

A. Performance e consultas

  • N+1 queries (loop que dispara query por item)\ Sinais: .ToList() cedo demais + depois acessando navegações; lazy loading sem controle; foreach com FirstOrDefault/Single no DbSet.
  • Client evaluation / materialização precoce\ Sinais: .AsEnumerable() cedo; projeção depois do materialize; ToList() antes de Where/Select.
  • Tracking desnecessário em leituras\ Sinais: queries de leitura sem .AsNoTracking() (quando não vai atualizar).
  • Includes excessivos / “cartesian explosion”\ Sinais: muitos .Include().ThenInclude() em coleções; retorno gigante; lentidão e memória alta.
  • Paginação incorreta\ Sinais: Skip/Take sem OrderBy; paginação feita em memória.
  • Projeção ineficiente\ Sinais: buscar entidade inteira quando só precisa de 3 campos (não usa Select para DTO).

B. Ciclo de vida do DbContext / concorrência

  • DbContext como Singleton (grave)\ Sinais: registrado como singleton; guardado em campo estático; reusado entre requests.
  • DbContext compartilhado em paralelo\ Sinais: Task.WhenAll com o mesmo context; uso em threads múltiplas.
  • Transações mal gerenciadas\ Sinais: múltiplos SaveChanges() em fluxo crítico sem transação; mistura de conexões.

C. Arquitetura e acoplamento

  • “Repository pattern em cima do EF” (o “repository do repository”) — muitas vezes vira redundância e piora consultas\ Sinais: GenericRepository<T> com GetAll() retornando IEnumerable<T>; falta de IQueryable controlado; specifications ruins.
  • Exposição de IQueryable para camadas superiores sem contrato (vazamento de infraestrutura)\ Sinais: services/controladores montando query arbitrária sobre DbSet.
  • Domínio acoplado ao EF\ Sinais: Entities com atributos de EF por todo lado, lógica de negócio misturada com navegações e carregamentos.

D. Modelagem e consistência

  • Entidades anêmicas + lógica no Service gigante
  • Falta de invariantes no domínio (entidade aceita estados inválidos)
  • Migrations caóticas, sem revisão; alteração de schema arriscada
  • Uso indevido de lazy loading (especialmente fora do request)

✅ Resultado: eu costumo classificar cada achado como (P0 crítico / P1 alto / P2 médio / P3 baixo) com “como reproduzir” e “como corrigir”.


2) SOLID — O que vou medir no seu código

SRP (Single Responsibility)

  • Classes “Deus” (Service/Manager com 1000+ linhas)
  • Handlers/Controllers fazendo: validação + regra + persistência + integração + mapping + logging tudo junto

OCP (Open/Closed)

  • switch/case gigante por tipo/status/canal
  • Ifs espalhados por toda parte para variações previsíveis (ex.: regras por “tipo de cliente”)

LSP (Liskov)

  • Heranças onde subclasses quebram contrato (lança exceptions inesperadas; altera semântica)

ISP (Interface Segregation)

  • Interfaces “gordas”: IService com 20 métodos, implementações forçadas a “não usar metade”

DIP (Dependency Inversion)

  • Domínio/Application dependendo de EF/infra diretamente
  • Services instanciando dependências com new (sem DI)
  • Dependência em classes concretas, não abstrações

📌 Na prática, eu vou apontar:

  • quais dependências estão invertidas
  • onde extrair políticas (domínio) de mecanismos (infra)
  • onde aplicar Strategy/Policy/Specification sem exagero

3) Clean Code — Sinais objetivos que eu procuro

  • Nomes ruins (métodos genéricos: Process, Handle2, DoWork)
  • Métodos longos (muitos níveis de indentação, muitos parâmetros)
  • Complexidade ciclomática alta (muitos if, &&, ||, switch)
  • Duplicação de regras e validações
  • Exceptions como fluxo (try/catch controlando lógica)
  • Logs ruins (sem correlação, sem contexto, loga dados sensíveis)
  • Testabilidade baixa (métodos estáticos, dependências escondidas, código sem interfaces)
  • Mistura de camadas (Controller acessa DbContext direto; Application acessa HttpClient sem abstração, etc.)

Se você quiser rodar a varredura aí (e só me mandar os outputs)

Aqui vai um “kit rápido” de checks úteis (você roda e cola os resultados):

1) Build e warnings

dotnet build -c Release

2) Formatação (se já tiver dotnet format configurado)

dotnet format

3) Analyzers recomendados (se puder adicionar)

  • SonarAnalyzer.CSharp
  • StyleCop.Analyzers
  • Microsoft.CodeAnalysis.NetAnalyzers

4) Métricas (se você usa VS Enterprise: Code Metrics)

Ou me mande um print/export das métricas de Maintainability / Cyclomatic Complexity.

Se você me mandar:

  • lista dos Top 20 arquivos por complexidade
  • e os Top 20 por duplicação / warnings\ eu já consigo apontar o grosso das violações.

Como você pode me enviar para eu analisar agora

✅ Melhor caminho:

  1. Compacte voyager (sem bin/obj)
  2. Garanta que não vai appsettings.Production.json com segredos
  3. Faça upload aqui do ZIP

Ou, se não puder mandar o repo todo:

📂 Envie estas pastas/arquivos (já dá para um diagnóstico bem forte):

  • *.csproj, Directory.Build.props/targets (se houver)
  • Camada de infraestrutura/dados: DbContext, EntityTypeConfigurations, Migrations
  • Services/UseCases/Handlers principais
  • Controllers (ou endpoints minimal)
  • 3–5 fluxos críticos (ex.: criação de ordem, fechamento, cálculo, etc.)
  • Um exemplo de query “pesada” (ex.: listagem com filtros)

Próxima pergunta (para eu começar do jeito certo)

Você prefere que eu faça a avaliação:

  1. Foco performance EF (N+1, includes, tracking, paginação, concorrência)
  2. Foco arquitetura SOLID/Clean (camadas, acoplamento, coesão, testes)
  3. Equilibrado (um pouco de cada, com priorização)

Se você me mandar o ZIP (ou um recorte do projeto), eu começo a revisão e te devolvo um relatório com achados e recomendações práticas.