Projete arquitetura de aplicações e soluções de integração no Azure
Escolha mensageria, streaming e roteamento de eventos, cache, gerenciamento de APIs, automação de infraestrutura e configuração centralizada a partir dos requisitos.
Tempo de estudo sugerido: 96 minutos • Nível intermediário • Reescrita autoral completa com resumo conciso de cada tópico
Por João Ricardo Dutra••Conteúdo autoral completo
1. Comece pela carga distribuída e seus contratos
Um monólito mantém chamadas e estado no mesmo processo. Uma aplicação de nuvem costuma separar front-ends, , workers, funções e dados para que cada parte seja implantada e dimensionada de forma independente. Essa liberdade introduz estado distribuído, trabalho paralelo, conclusão assíncrona, falhas parciais e contratos versionados.
A plataforma fictícia de demonstrações da Tailwind Traders deve receber avaliações e mídias, avisar aplicativos móveis no mundo todo, exibir ofertas que mudam rapidamente, publicar para parceiros, implantar com frequência e separar configuração de código. Uma arquitetura pronta para IA pode acrescentar funções acionadas ou back-ends inteligentes, mas continua dependendo de comunicação confiável e governança.
Distinguir comandos e mensagens de notificações de eventos.
Escolher filas, tópicos, e roteamento conforme a entrega exigida.
Projetar , integração de , implantação automatizada e configuração centralizada.
Avaliar segurança, resiliência, escala, operação e custo do fluxo completo.
Resumo do tópico
Mapeie produtores, consumidores, contratos, estado, escala, latência, falhas e responsáveis antes de escolher um serviço do .
2. Mensagens e eventos expressam intenções diferentes
Uma mensagem leva os dados necessários para que um destinatário execute uma ação esperada. O emissor solicita trabalho e normalmente se importa com a conclusão. Uma de upload, por exemplo, pode enfileirar os detalhes do arquivo para um worker validar o vídeo ou criar miniaturas.
Um evento declara que algo aconteceu. O publicador não ordena uma ação específica e pode não saber se zero, um ou muitos assinantes têm interesse. Eventos devem ser fatos leves e, em geral, conter uma referência ao objeto alterado em vez do objeto inteiro.
A intenção define o modelo: solicite trabalho com uma mensagem; anuncie um fato com um evento.
Resumo do tópico
Use mensagem quando o processamento é obrigatório e evento quando consumidores independentes podem reagir a um fato.
3. A semântica de entrega faz parte do contrato
A entrega no máximo uma vez evita reenvio, mas pode perder trabalho. A entrega pelo menos uma vez protege o trabalho com reenvios; por isso o consumidor deve ser idempotente e eliminar duplicidades quando o efeito de negócio não puder se repetir. A ordem costuma existir apenas na fila, sessão, partição ou chave definida, e não no sistema distribuído inteiro.
Defina confirmação, repetição, ,, duração do bloqueio, expiração e tratamento de mensagens venenosas.
Use uma chave de correlação ou idempotência e torne cada transição de estado segura para repetição.
Diferencie entrega do transporte e conclusão de negócio: uma mensagem aceita não prova que o pedido terminou.
Monitore idade do item mais antigo, backlog, dead letters, , latência e taxa de falhas.
Resumo do tópico
Transporte confiável ainda exige consumidores idempotentes, política explícita de repetição, observabilidade e recuperação de mensagens inválidas.
4. do cria um backlog simples e durável
O do integra uma conta de do e pode conter milhões de mensagens dentro da capacidade da conta. Produtores e workers usam /, e as mensagens sobrevivem a indisponibilidades temporárias. É adequado a trabalho assíncrono desacoplado, backlogs grandes, acompanhamento de progresso e trilhas simples que não exigem recursos avançados de broker.
O tem limite de 64 KB. Armazene mídia grande no e coloque na fila um identificador protegido e os necessários. O de visibilidade oculta temporariamente um item recebido; o consumidor o exclui após sucesso ou permite que volte a ficar visível.
O prioriza backlog simples; o acrescenta semântica corporativa.
Resumo do tópico
Escolha para uma fila durável, econômica e muito grande quando recursos avançados de broker não forem necessários.
5. do é um broker de mensagens corporativo
O do desacopla aplicações entre limites de rede e organização por meio de filas e tópicos. Atende mensagens de negócio de alto valor que precisam de detecção de duplicidade, transações, sessões, ordenação por sessão, entrega agendada, dead letter, filtros e protocolos orientados pelo broker.
Uma fila usa consumidores concorrentes: cada mensagem é processada por um receptor disponível. PeekLock bloqueia sem excluir e oferece comportamento pelo menos uma vez; Complete remove a mensagem. ReceiveAndDelete entrega no máximo uma vez e pode perder o item se o processamento falhar depois da recepção.
Resumo do tópico
Use quando o trabalho exigir confiabilidade, transações, roteamento, ordenação ou operação de dead letter no broker.
6. Tópicos e assinaturas fornecem publicação e assinatura durável
Um tópico do recebe uma mensagem e a copia para as assinaturas compatíveis. Cada assinatura funciona como uma fila com backlog, consumidores, filtros e ciclo de vida próprios. Uma mensagem “produto acompanhado” pode ir tanto para o histórico quanto para a lista de fãs.
Assinaturas isolam consumidores e permitem distribuição durável com filtros.
Use tópico quando cada destino precisar de uma cópia durável. Use fila quando apenas um consumidor concorrente deve executar o trabalho. Não confunda um tópico do broker com uma notificação efêmera.
Resumo do tópico
Tópicos do distribuem mensagens de um para muitos; cada assinatura filtrada mantém sua própria cópia.
7. e atendem requisitos diferentes
Critérios de seleção de filas.
Requisito
Fila ou tópico do
Capacidade do backlog
Muito grande, limitada pela capacidade da conta.
Limites de entidade e variam por camada.
Tamanho
Até 64 KB.
maior conforme camada e protocolo; use -check para corpos grandes.
Entrega
e de visibilidade.
Protocolos de broker, PeekLock ou ReceiveAndDelete.
Semântica avançada
Implementada principalmente pela aplicação.
Transações, sessões, duplicidade, agenda, dead letter e filtros.
Uso típico
Backlog simples e acompanhamento de processamento.
Pedidos, finanças, workflows e integração corporativa.
Resumo do tópico
Escolha a fila por entrega, transação, roteamento, ordem, tamanho, backlog e operação, e não apenas pelo nome “fila”.
8. do ingerem ordenados em alto volume
Os do são um serviço gerenciado de de para telemetria, clickstreams, sensores, , fraude e análise de transações. Podem receber milhões de eventos por segundo, expor o fluxo a vários processadores e capturá-lo no do para análise posterior.
O é somente acréscimo e fica ordenado dentro de cada partição pela chegada. Consumidores fazem pull e controlam offsets; a leitura não exclui dados, portanto aplicações independentes podem reproduzir a janela retida. O serviço não possui um caminho de dead letter de fila para registros que um consumidor não consegue processar.
Resumo do tópico
Escolha para uma série particionada e retida de observações em alto volume que pode ser reproduzida.
9. Partições, grupos de consumidores e offsets definem o paralelismo
Uma partição é um ordenado e uma unidade de paralelismo. A chave de partição mantém eventos relacionados juntos quando a ordem local importa. Um grupo de consumidores oferece uma visão independente do ; normalmente cada partição tem um proprietário ativo por grupo.
Provisione partições suficientes para o paralelismo planejado sem criar complexidade gratuita.
Registre checkpoints somente após processamento seguro e planeje reprodução e duplicidades.
Separe grupos para fraude, , enriquecimento e outros consumidores independentes.
Trate retenção como janela de reprodução, não como armazenamento corporativo permanente.
Resumo do tópico
Chaves preservam ordem local, grupos isolam leitores e checkpoints tornam a reprodução uma capacidade operacional deliberada.
10. Capacidade e camada dos precisam ser medidas
Nas camadas Básica e Standard, uma unidade de produtividade oferece até 1 MB/s ou 1.000 eventos/s de entrada e 2 MB/s ou 4.096 eventos/s de saída, prevalecendo o limite atingido primeiro. Standard pode usar expansão automática. Premium usa unidades de processamento isoladas; a capacidade real varia com , produtores, consumidores, partições e protocolo e precisa de teste de carga.
As camadas diferem em tamanho do evento, retenção, partições, rede, Capture, chaves gerenciadas pelo cliente, recursos geográficos e isolamento. Premium retém por até 90 dias e permite expansão dinâmica de partições; Dedicated oferece de locatário único. Valide cotas e regiões atuais.
Resumo do tópico
Estime eventos, bytes, partições, leitores e retenção; depois teste a camada e monitore e atraso.
11. Um separa , armazenamento e análise
Um desenho comum envia produtores aos , captura dados brutos no de Blobs ou , processa o fluxo ao vivo com e publica medidas em ou armazenamentos operacionais. O armazenamento preserva evidências enquanto processadores evoluem de modo independente.
Separe , processamento em tempo real e histórico para que cada estágio escale e se recupere.
Planeje , checkpoints, evolução de , registros atrasados ou fora de ordem, quarentena de eventos inválidos e recuperação. Retenção do Hub não substitui arquivo governado.
Resumo do tópico
Um resiliente guarda dados brutos, isola consumidores e explicita reprodução, e falhas posteriores.
12. do roteia mudanças discretas de estado
A do é um serviço gerenciado de publicação e assinatura para distribuição altamente escalável. Serviços e publicadores personalizados anunciam mudanças de estado; a Grade filtra e roteia para ,, e outros manipuladores sem constante.
Um evento de blob criado deve conter tipo, instante, assunto e ou identificador do objeto, não o blob. Assim a notificação permanece leve e cada assinante busca o objeto protegido quando necessário.
Resumo do tópico
Use a para reagir a mudanças discretas e conectar publicadores a manipuladores independentes.
13. Origens, tópicos, assinaturas, filtros e manipuladores formam a rota
O publicador envia a um tópico de sistema, personalizado, domínio, parceiro ou . A assinatura escolhe eventos por tipo ou atributo e define o manipulador ou modo de entrega. O manipulador valida, autoriza e processa de modo idempotente.
Tópicos organizam publicação; assinaturas filtram; manipuladores são donos da reação.
Autentique publicadores e manipuladores com ou credenciais compatíveis.
Valide propriedade do e .
Configure repetição, expiração, destino de dead letter quando disponível e alertas.
Evite ciclos e documente todas as dependências da distribuição.
Resumo do tópico
O design só está completo com tópico, , filtro, entrega, repetição, segurança e idempotência definidos.
14. Entrega push e pull atende consumidores diferentes
No push, a chama um destino público registrado, como ou Function. Isso elimina e serve a manipuladores capazes de expor e validar um . No pull, a aplicação lê um tópico de da no próprio ritmo, com confirmação semelhante à fila.
Use pull quando o consumidor controlar o instante, não puder expor , precisar de Private Link no consumo ou quiser liberar o evento para depois. Use push para reação imediata com entrada pública aceitável. Ambos exigem idempotência.
Resumo do tópico
Push favorece imediato; pull favorece ritmo do consumidor, conectividade privada e controle semelhante a fila.
15. , e têm papéis distintos
Distinção principal dos serviços.
Serviço
Unidade
Consumo
Exemplo
do
Evento discreto de mudança.
Distribuição reativa por push ou pull.
Reagir a blob ou status de pedido.
do
Série ordenada de telemetria.
particionado com reprodução.
Ingerir cliques, sensores, ou jogo.
do
Comando ou mensagem de alto valor.
Filas e assinaturas duráveis.
Atender pedidos ou transações.
do
Tarefa assíncrona simples.
Backlog grande consultado por .
Processar arquivos ou jobs.
Uma aplicação pode combinar os quatro serviços para contratos diferentes.
Resumo do tópico
Combine serviços: comandos para trabalho obrigatório, para observações e eventos roteados para reações.
16. Coloque em apenas dados cuja desatualização e perda sejam conhecidas
copia dados lidos com frequência para armazenamento rápido próximo da aplicação. Funciona melhor quando a origem é relativamente estática, disputada ou distante. Pode reduzir latência, carga no banco e quantidade de servidores.
O design deve registrar fonte da verdade, desatualização aceitável, expiração, remoção, invalidação, aquecimento, capacidade, serialização, controle de avalanche e comportamento sem . O não deve virar silenciosamente a única cópia durável.
Resumo do tópico
O design de começa por atualização, invalidação, falha e fonte da verdade, e não apenas por menor latência.
17. é o serviço Redis atual
O é um serviço em memória totalmente gerenciado e compatível com Redis, baseado no Redis Enterprise. Aplicações dentro ou fora do podem usá-lo como de dados ou conteúdo, sessão, coordenação ou broker e combiná-lo com , e outras origens.
Camadas de desempenho.
Camada
Perfil
Uso
Otimizada para Memória
Alta proporção memória/vCPU.
Carga intensiva em memória.
Equilibrada
Memória e computação equilibradas.
Ponto inicial de uso geral.
Otimizada para Computação
Alta proporção vCPU/memória.
Throughput e latência exigentes.
Otimizada para Flash
RAM e flash NVMe de menor custo.
Datasets grandes que aceitam trade-off.
Resumo do tópico
Selecione a camada por memória, throughput, latência, disponibilidade, persistência e tamanho medidos.
18. Planeje a migração do
O será desativado. Na nuvem pública, novas instâncias Básica, Standard e Premium ficam bloqueadas para novos clientes desde 1º de abril de 2026 e para clientes existentes em 1º de outubro de 2026; as restantes serão desligadas a partir de 1º de outubro de 2028. O cronograma Enterprise é diferente e anterior. Novos projetos devem usar .
Não presuma equivalência de SKU. Meça pico de memória usada, throughput, conexões, latência, módulos, persistência, clustering, rede, autenticação, replicação geográfica e clientes. Teste , cutover e .
Resumo do tópico
Migração Redis é um projeto de arquitetura e compatibilidade, com dimensionamento medido e troca testada.
19. Aplique padrões de de forma deliberada
Padrões comuns.
Padrão
Objetivo
Decisão crítica
de dados
Reduzir leituras repetidas.
-aside, , remoção, invalidação e avalanche.
de conteúdo
Servir banners, templates e fragmentos.
Versionar e invalidar na publicação.
de sessão
Retirar carrinho ou sessão das instâncias Web.
Proteger ID, definir e continuidade regional.
Fila de jobs/mensagens
Adiar operações longas.
Confirmar se a semântica Redis atende ao negócio.
Transação distribuída
Executar lote de comandos Redis atomicamente.
A atomicidade não atravessa sistemas independentes.
Resumo do tópico
O padrão nomeado esclarece propriedade e falha, mas não dispensa a validação da semântica do serviço.
20. -aside mantém a origem como autoridade
No -aside, a aplicação consulta o ; no miss, lê a origem, devolve e popula o . Uma gravação atualiza a origem e invalida ou renova o valor. limita desatualização; jitter, coalescência e locks reduzem misses sincronizados.
O banco continua autoritativo e o pode ser reconstruído.
Proteja Redis com rede privada quando aplicável, , menor privilégio, identidade sem segredo quando disponível, rotação, monitoramento e limites. Defina se a aplicação recorre ao banco, degrada funções ou rejeita trabalho durante falha.
Resumo do tópico
-aside é resiliente quando o é descartável, misses são controlados e a origem suporta o fallback previsto.
21. Integração de precisa de uma porta de entrada governada
Publicar amplia alcance, mas cada interface cria onboarding, segurança, versões, documentação, análises, cotas e suporte. A Tailwind Traders atende aplicativos, Web, dispositivos em veículos, fornecedores, equipes internas e analistas, com back-ends distribuídos.
Gerenciamento central ganha valor conforme crescem quantidade de , ritmo de mudança, diversidade de consumidores e carga de políticas. Um inventário pequeno e estático pode não justificar plataforma e custo.
Resumo do tópico
Quantifique , consumidores, mudanças, exposição, políticas e administração antes de recomendar uma plataforma.
22. separa e gerenciamento
O publica, protege, mantém e analisa . O recebe tráfego, aplica políticas e encaminha chamadas; o plano de gerenciamento controla configuração; o portal do desenvolvedor apoia descoberta e onboarding. O serviço não hospeda a de negócio: o back-end continua onde foi implantado.
cria uma fachada governada sem mover a lógica do back-end.
Resumo do tópico
desacopla contrato público e políticas transversais dos back-ends distribuídos.
23. Políticas padronizam segurança e tráfego
Autentique e autorize com ,, certificados, assinaturas ou mecanismos compatíveis.
Aplique cotas, rate limits, validação, transformações, , roteamento, repetições e proteção do back-end.
Publique especificações, , produtos, revisions e versions consistentes.
Colete telemetria, correlacione chamadas, audite mudanças e proteja segredos com e do .
Policies não substituem autorização de domínio, ou implementação segura do back-end. Defina o dono de cada controle e evite dados confidenciais em .
Resumo do tópico
Use para controles transversais consistentes e mantenha regras de negócio no serviço proprietário.
24. Escolha topologia e camada do pelos requisitos
As camadas clássicas Developer, Basic, Standard e Premium atendem cenários estabelecidos. Basic v2, Standard v2 e Premium v2 provisionam e escalam mais rápido; Standard v2 e Premium v2 incluem opções para back-ends isolados, e Premium v2 acrescenta escala corporativa e isolamento completo de rede virtual. Consumo atende tráfego variável. Workspaces delegam propriedade, e auto-hospedado aproxima o plano de dados de back-ends híbridos.
Recursos, limites, regiões, rede, workspaces, zonas, multirregião, e custo variam e evoluem. Valide a matriz atual; não há migração genérica automatizada no local de uma instância clássica ou Consumo para v2.
Resumo do tópico
Camada e topologia seguem , throughput, isolamento, região, delegação, híbrido, recursos e custo.
25. Infraestrutura como código torna a implantação repetível
Infraestrutura como código guarda estado desejado em arquivos versionados. Revisão, testes, aprovações e governam aplicação e plataforma juntas. A implantação declarativa descreve o destino e o mecanismo calcula dependências.
Separe ambientes e escopos, proteja segredos, fixe versões de módulos, valide políticas, visualize mudanças, registre evidências e defina ou roll-forward. Repetição não é segurança se o template contiver intenção destrutiva.
Resumo do tópico
IaC transforma infraestrutura em artefato revisável, mas exige validação, aprovação, evidência e recuperação.
Modelos do descrevem recursos em . São idempotentes, validados antes do provisionamento, criam recursos independentes em paralelo e compõem componentes vinculados ou aninhados. What-if na CLI do ou PowerShell antecipa criações, alterações e exclusões.
Integram-se ao , GitHub Actions e outras ferramentas de CI/CD. Scripts de implantação executam Bash ou PowerShell quando o recurso declarativo não basta, mas devem ser exceções repetíveis, protegidas e observáveis.
Resumo do tópico
Modelos são declarativos, combináveis, visualizáveis e integrados a ; scripts imperativos são exceções controladas.
27. é a experiência preferida de criação para
é uma linguagem específica de domínio para implantação declarativa no . Compila para e oferece sintaxe concisa, tipos, módulos, tooling e acesso imediato aos tipos de recurso. O armazena o estado da implantação, sem arquivo de estado separado.
A CLI descompila existente, mas o resultado exige revisão. Use módulos, lint, what-if, controles de ciclo de vida e identidade de CI/CD com menor privilégio.
melhora a criação; o Resource Manager continua sendo o mecanismo de implantação.
Resumo do tópico
Use para IaC sustentável e valide implantação e permissões por governado.
28. do executa processos operacionais repetíveis
A do oferece automação de processos para ambientes e não . Runbooks PowerShell e Python, agendas, , e Hybrid Runbook Workers automatizam tarefas frequentes, demoradas ou sujeitas a erro.
Controle de Alterações e Inventário usa coleta com Agente do para software, serviços ou daemons, registro e arquivos. Configuração de Estado da do será desativada em 30 de setembro de 2027; novos projetos devem usar Configuração de Máquina do por . Runbooks precisam de idempotência, , repetição, concorrência e menor privilégio.
Resumo do tópico
Use para runbooks governados e planeje agentes atuais e substitutos de recursos em desativação.
29. cuida dos patches atuais
A antiga solução Update Management da do foi desativada em 31 de agosto de 2024. O é o serviço atual para avaliar e agendar atualizações de sistema operacional, definir janelas e orquestrar patches em VMs do e servidores Windows e Linux habilitados pelo .
O design inclui classificação, cadência, reboot, tarefas pré/pós, exclusões, validação, anéis, conformidade e restrições de . implanta recursos desejados; Update Manager orquestra patches do sistema operacional.
Resumo do tópico
Separe implantação de infraestrutura da operação de patches; use o Gerenciador de Atualizações para o agendamento atual.
30. do separa settings das versões
A do centraliza pares chave-valor e feature . Oferece integração com , labels, comparação de conjuntos, snapshots imutáveis para e auditoria e réplicas geográficas com consistência eventual.
Feature liberam comportamento sem reimplantar código, mas precisam de dono, regras, validade, telemetria e limpeza. A atualização de configuração deve definir ou push, , e comportamento sem a loja.
Resumo do tópico
Configuração central acelera mudanças apenas com , snapshots, atualização, propriedade, resiliência e limpeza governados.
31. Mantenha settings, identidades e segredos no serviço correto
Aplicações devem usar identidades gerenciadas do e receber apenas funções de plano de dados necessárias. Use pontos de extremidade privados e controles de rede quando exigidos, criptografia, monitoramento, exclusão reversível e proteção contra limpeza.
guarda settings não secretos e pode referenciar segredos no do . A identidade busca o segredo sem credencial no código. Desenvolvimento usa , e CLI do com identidade de pessoa; produção usa identidade da carga e lojas, labels ou snapshots governados separadamente.
Separe ambientes e deixe identidades gerenciadas acessarem configuração e segredos referenciados.
Resumo do tópico
Use para settings, para segredos e identidades gerenciadas para acesso.
32. Avaliação, registro de decisão e próximos estudos
Aplique ao jogo de recompensas.
Requisito
Resposta
Motivo
Agrupar detalhes da compra em uma transação confiável.
Fila do do
Broker corporativo com transações e entrega confiável.
Instalar atualizações numa janela de manutenção.
Serviço atual de avaliação e orquestração de patches.
Receber milhões de eventos/s com baixa latência e salvar em Blob.
do
de e Capture ou arquivo posterior.
Registre produtor, consumidor, intenção, contrato, entrega, escala, partição, ordem, repetição, dead letter, identidade, rede, criptografia, observabilidade, custo, região, implantação, configuração e teste de recuperação. A mesma aplicação pode usar Barramento para pedidos, Hubs para telemetria, Grade para reações, Redis para leituras quentes, para acesso, para implantação, para runbooks, Update Manager para patches e para settings.
Pratique com perguntas comparativas
Explique arquitetura por mensagens e por eventos com dois exemplos adequados de cada.
Compare , filas e tópicos do Barramento por entrega, roteamento, tamanho, transação e custo.
Compare Hubs e , incluindo reprodução, push/pull, ordem e falhas.
Revise limites e disponibilidade regional oficiais antes da implementação.
