Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame DP-420 avalia. Leia de cima a baixo ou pule para uma seção.
Existe um relacionamento de um para poucos onde os dados relacionados são limitados, pequenos e frequentemente lidos em conjunto.
Incorporar os dados relacionados como um objeto ou array aninhado dentro do documento principal.
Por quê: Otimiza o desempenho de leitura recuperando todos os dados necessários em uma única leitura pontual, minimizando o custo de RU e a latência. Evita junções (joins) do lado do cliente.
Um relacionamento de um para muitos onde o lado "muitos" cresce ilimitadamente ou é atualizado independentemente do lado "um".
Armazenar itens relacionados como documentos separados e usar o ID do documento pai como referência.
Por quê: Impede que os documentos excedam o limite de tamanho de 2 MB e evita altos custos de RU para atualizações em grandes arrays incorporados.
Um documento contém um array que pode crescer ilimitadamente ao longo do tempo, arriscando o limite de tamanho de documento de 2 MB (por exemplo, logs de eventos, comentários).
Dividir o array em vários documentos "bucket". Quando um bucket atinge um limite de tamanho/item, criar um novo.
Por quê: Mantém os tamanhos dos documentos individuais gerenciáveis enquanto preserva o agrupamento lógico dos dados relacionados.
Modelagem de um relacionamento de muitos para muitos, como estudantes e cursos, ou artigos e tags.
Para relacionamentos limitados, duplicar dados de relacionamento em ambos os lados (por exemplo, incorporar IDs de curso no documento de estudante, IDs de estudante no documento de curso). Para relacionamentos ilimitados, usar um contêiner de documento "join" ou "edge" separado.
Por quê: A desnormalização otimiza para ambas as direções de consulta (estudantes em curso, cursos para estudante) sem exigir joins. Um contêiner de join é para casos ilimitados.
Modelagem de dados hierárquicos (por exemplo, organograma, categorias de produtos) e necessidade de consultar todos os descendentes de um nó.
Armazenar um array de todos os IDs ou nomes dos ancestrais (o caminho) em cada documento.
Por quê: Permite consultas eficientes de subárvores com um único `ARRAY_CONTAINS` filter, evitando pesquisas recursivas custosas.
Um documento possui um array ilimitado (por exemplo, comentários de blog), mas a consulta mais comum precisa apenas dos N itens mais recentes.
Incorporar um subconjunto de itens recentes no documento principal e armazenar todos os itens como documentos referenciados separados.
Por quê: Otimiza o caminho de leitura primário para desempenho e custo, enquanto ainda permite o acesso ao conjunto de dados completo quando necessário.
Armazenar uma sequência de eventos imutáveis para uma entidade e precisar consultar o estado atual ou agregados analíticos.
Armazenar eventos em um único contêiner particionado pelo ID da entidade. Usar Change Feed ou Synapse Link para calcular e armazenar materialized views ou agregados.
Por quê: Fornece um registro de auditoria completo e desacopla o modelo de escrita de vários modelos de leitura, oferecendo alta flexibilidade.
Necessidade de preservar o estado de dados relacionados em um ponto específico no tempo (por exemplo, o endereço de um cliente em um pedido).
Incorporar uma cópia (snapshot) dos dados relacionados no documento, em vez de referenciá-los.
Por quê: Garante a precisão histórica, desacoplando o documento de futuras alterações nos dados referenciados.
Ingerir dados de séries temporais de alta frequência (por exemplo, leituras de sensores IoT) e consultar por dispositivo em intervalos de tempo.
Usar o ID do dispositivo como chave de partição. Agregar leituras em documentos agrupados por tempo (por exemplo, por hora ou por minuto) em vez de um documento por leitura.
Por quê: Reduz drasticamente a contagem de documentos e RUs de escrita, enquanto co-localiza dados para consultas eficientes de intervalo de tempo dentro de uma partição.
Necessidade de realizar múltiplas operações de criação, atualização ou exclusão como uma única transação atômica.
Usar o recurso TransactionalBatch do SDK. Todas as operações devem ter como alvo a mesma chave de partição lógica.
Por quê: Oferece garantias ACID para até 100 operações dentro de uma única partição, garantindo que todas as operações sejam bem-sucedidas ou que todas falhem juntas.
Documentos devem ser automaticamente excluídos de um contêiner após um período específico (por exemplo, 30 dias).
Habilitar Time to Live (TTL) no contêiner e definir o valor `ttl` padrão em segundos (por exemplo, 2592000 para 30 dias). Um `ttl` de -1 em um documento individual sobrescreve o padrão e impede a expiração.
Por quê: TTL é um recurso sem custo que usa RUs restantes para realizar exclusões em segundo plano, fornecendo uma maneira eficiente e sem intervenção para gerenciar o ciclo de vida dos dados.
Necessidade de armazenar grandes objetos binários (imagens, vídeos, documentos > 2 MB) associados a metadados do Cosmos DB.
Armazenar o objeto binário no Azure Blob Storage. Armazenar o URI para o blob no documento Cosmos DB junto com os metadados.
Por quê: O Cosmos DB é otimizado para metadados estruturados e tem um limite de documento de 2 MB. O Blob Storage é um serviço escalável e econômico para armazenamento de grandes objetos.
Os mesmos dados precisam ser consultados por diferentes propriedades, levando a consultas ineficientes entre partições (por exemplo, consultar pedidos por cliente e depois por produto).
Usar o Change Feed para popular um segundo contêiner (uma materialized view) com os mesmos dados, mas particionado pela propriedade de consulta secundária.
Por quê: Move o cálculo do tempo de leitura para o tempo de escrita, permitindo consultas eficientes de partição única para múltiplos padrões de acesso.
Necessidade de executar consultas analíticas complexas (agregações, joins) em dados operacionais em tempo real sem impactar a carga de trabalho transacional.
Habilitar Azure Synapse Link no contêiner Cosmos DB. Executar consultas analíticas no analytical store do contêiner usando Synapse serverless SQL ou Spark pools.
Por quê: Fornece uma solução HTAP nativa da nuvem, sem ETL. As consultas contra o analytical store colunar não consomem RUs transacionais e são altamente performáticas.
Necessidade de acionar ações downstream de forma escalável, confiável e serverless em resposta a alterações de dados.
Usar uma Azure Function com o gatilho Cosmos DB. O gatilho utiliza a biblioteca Change Feed Processor automaticamente.
Por quê: Este é o padrão recomendado para arquiteturas orientadas a eventos. Ele oferece escalonamento automático, checkpointing e gerenciamento de leases de partição.
Uma operação deve atualizar atomicamente o banco de dados e publicar uma mensagem para um sistema de mensagens (por exemplo, Service Bus, Event Hubs).
Realizar a escrita no banco de dados. Usar um processador Change Feed para ler de forma confiável a alteração confirmada e publicar a mensagem correspondente, com lógica de retry.
Por quê: Evita escritas duplas não confiáveis e a necessidade de transações distribuídas. O Change Feed atua como uma caixa de saída durável, garantindo a entrega eventual da mensagem.
Escolher uma chave de partição para um novo contêiner para garantir desempenho e escalabilidade.
Selecionar uma propriedade com alta cardinalidade que esteja presente na maioria, se não em todas, as operações de leitura pontual e de consulta.
Por quê: Alinhar a chave de partição com o filtro de consulta mais comum garante que a maioria das operações seja roteada para uma única partição lógica, que é o padrão de acesso mais eficiente.
Um único valor de chave de partição recebe um volume desproporcionalmente alto de solicitações, causando limitação (throttling) (uma "hot partition").
Criar uma chave de partição sintética concatenando a chave original com um sufixo aleatório ou outra propriedade de alta cardinalidade (por exemplo, `userId + "-" + random(1-10)`).
Por quê: Distribui a carga de escrita e leitura para uma única entidade lógica por várias partições físicas, mitigando a limitação.
Os dados precisam ser particionados por múltiplos níveis (por exemplo, tenant, depois ano, depois mês) para evitar partições grandes e suportar consultas de múltiplos níveis.
Configurar uma chave de partição hierárquica com um array ordenado de caminhos, como `["/tenantId", "/year"]`.
Por quê: Permite o sub-particionamento para evitar o limite de partição lógica de 20 GB e possibilita um roteamento mais eficiente para consultas que filtram na hierarquia.
Uma aplicação distribuída globalmente com escritas multi-região habilitadas precisa lidar com atualizações concorrentes no mesmo documento.
Para sobrescritas simples, usar Last-Writer-Wins (LWW). Para operações que exigem lógica de fusão (merge logic) (por exemplo, incrementar um contador, atualizar inventário), usar uma política de resolução de conflitos personalizada com uma stored procedure de fusão.
Por quê: A lógica de fusão personalizada evita a perda de dados (por exemplo, um incremento perdido) que ocorreria com LWW, garantindo a integridade dos dados para operações de negócios críticas.
Equilibrar latência de leitura, disponibilidade e consistência de dados para uma aplicação distribuída globalmente.
Padrão para consistência de Sessão para um bom equilíbrio e read-your-own-writes. Usar Bounded Staleness para atraso de leitura previsível. Sobrescrever operações críticas de escrita/leitura específicas para consistência Forte conforme necessário.
Por quê: Sessão é o nível mais amplamente utilizado, fornecendo baixa latência e fortes garantias dentro de uma sessão de cliente. Sobrescrever por solicitação permite flexibilidade.
As operações de escrita estão consumindo RUs excessivas, e apenas um pequeno subconjunto de propriedades do documento é usado em filtros de consulta.
Mudar da política de indexação padrão para uma política personalizada. Incluir explicitamente os caminhos para as propriedades consultadas e excluir todos os outros caminhos (`"/*"` em `excludedPaths`).
Por quê: Cada propriedade indexada incorre em um custo de RU nas escritas. Excluir propriedades não utilizadas pode reduzir significativamente o consumo de RU de escrita e o tamanho do armazenamento do índice.
Uma consulta frequente filtra por uma propriedade e ordena por outra (por exemplo, `WHERE c.status = "active" ORDER BY c.timestamp DESC`).
Criar um índice composto nas propriedades na ordem em que aparecem na consulta: `(status ASC, timestamp DESC)` .
Por quê: Permite que o motor de consulta sirva o resultado filtrado e ordenado diretamente do índice, evitando uma custosa operação de ordenação em memória e reduzindo drasticamente a cobrança de RU.
Uma consulta recupera documentos grandes, mas o aplicativo precisa apenas de uma ou duas propriedades pequenas deles.
Usar projeção de consulta para selecionar apenas as propriedades necessárias (por exemplo, `SELECT c.id, c.name FROM c`) em vez de `SELECT *`.
Por quê: Reduz o custo de RU diminuindo o tamanho da carga de dados transferida do motor do banco de dados para o cliente.
Uma aplicação consulta frequentemente por atualizações de documentos, mas os dados mudam com pouca frequência, levando a altos custos de RU para leituras.
Armazenar o ETag da última leitura. Em leituras subsequentes, enviar o ETag em um cabeçalho `If-None-Match`.
Por quê: Se o documento não foi alterado, o Cosmos DB retorna um status 304 Not Modified com uma cobrança de RU mínima (normalmente ~1 RU), economizando custo e largura de banda.
Uma carga de trabalho possui padrões de tráfego variáveis ou imprevisíveis, com picos e vales significativos.
Configurar o autoscale de throughput no banco de dados ou contêiner. Definir o RU/s máximo necessário para a carga de pico.
Por quê: Dimensiona automaticamente o throughput entre 10% do máximo e o RU/s máximo com base no uso, otimizando custos ao não pagar pela capacidade provisionada ociosa.
Uma carga de trabalho é para desenvolvimento, teste ou uma aplicação de baixo tráfego com longos períodos de ociosidade.
Usar o modo de capacidade Serverless para a conta Cosmos DB.
Por quê: Você paga apenas pelos RUs consumidos por operação, sem capacidade mínima provisionada. Esta é a opção mais econômica para cargas de trabalho esporádicas.
Necessidade de ingerir ou modificar um grande número de documentos (milhares a milhões) o mais rápido possível.
Usar o recurso de suporte a operações em massa (bulk support) do SDK (por exemplo, `AllowBulkExecution = true` no .NET SDK v3).
Por quê: O SDK otimiza para alta throughput agrupando operações, gerenciando concorrência e lidando internamente com retries/throttling, superando em muito as operações sequenciais.
Uma stored procedure processando um grande lote de documentos está excedendo o tempo limite.
Implementar execução limitada. A stored procedure deve verificar se está se aproximando do limite de execução de 5 segundos e, se sim, retornar um token de continuação ao cliente. O cliente então re-invoca o procedimento com o token para retomar o processamento.
Por quê: Stored procedures têm um limite de tempo de execução rígido. Um padrão de continuação é a maneira padrão de lidar com lógica de servidor de longa duração e múltiplas etapas.
Uma aplicação de missão crítica requer alta disponibilidade com perda mínima de dados (RPO) e tempo de recuperação rápido (RTO) em caso de interrupção regional.
Configurar a conta Cosmos DB com múltiplas regiões de escrita e habilitar o failover automático.
Por quê: Fornece o menor RPO e RTO. Os dados são replicados entre regiões, e em caso de interrupção, o Cosmos DB promove automaticamente uma região secundária para ser a nova região de escrita primária.
Necessidade de poder se recuperar de exclusão ou corrupção acidental de dados restaurando o banco de dados para um ponto específico no tempo.
Habilitar o modo de Backup Contínuo na conta Cosmos DB.
Por quê: O backup contínuo permite restaurar para qualquer ponto no tempo (com precisão de segundos) dentro do período de retenção (7 ou 30 dias). A operação de restauração cria uma nova conta.
Um requisito de conformidade exige que as chaves de criptografia de dados sejam gerenciadas e controladas pelo cliente.
Configurar a conta Cosmos DB com Chaves Gerenciadas pelo Cliente (CMK), usando uma chave de um Azure Key Vault.
Por quê: Oferece uma camada adicional de segurança onde você controla o ciclo de vida da chave (incluindo rotação e revogação) para criptografia em repouso.
Necessidade de conceder a um aplicativo ou usuário acesso granular, baseado em identidade, aos dados, seguindo o princípio do menor privilégio.
Usar a integração com Azure AD e atribuir uma função interna (por exemplo, Cosmos DB Built-in Data Reader) ou uma função RBAC personalizada, com escopo para o contêiner ou banco de dados específico.
Por quê: Elimina a necessidade de gerenciar e compartilhar chaves mestras. O RBAC oferece controle de acesso auditável e baseado em identidade.
Uma conta Cosmos DB deve ser acessível apenas de dentro de uma Azure Virtual Network (VNet) específica, sem tráfego pela internet pública.
Criar um Private Endpoint para a conta Cosmos DB na VNet e desabilitar o acesso à rede pública nas configurações do firewall.
Por quê: Private Endpoints fornecem um endereço IP privado para a conta Cosmos DB dentro da sua VNet, garantindo que todo o tráfego flua pela backbone seguro do Azure.
Diagnosticar a causa raiz dos erros de limitação (throttling) HTTP 429 (Too Many Requests).
Monitorar a métrica "Consumo de RU Normalizado" no Azure Monitor. Usar os Logs de Diagnóstico (`CDBPartitionKeyRUConsumption`) para identificar quais chaves de partição estão consumindo mais RUs.
Por quê: O consumo de RU normalizado mostra se o throughput geral está esgotado. Os logs de nível de partição identificam hot partitions, que é uma causa comum de limitação mesmo quando o uso geral é baixo.
Necessidade de monitorar e alertar sobre a latência de solicitação para garantir a conformidade com o SLA.
Monitorar a métrica "Latência P99 do Lado do Servidor" no Azure Monitor. Criar uma regra de alerta para quando essa métrica exceder o limite do SLA.
Por quê: A latência P99 representa a pior experiência para 99% das solicitações e é na qual os SLAs do Cosmos DB são baseados. É um indicador mais significativo de problemas de desempenho do que a latência média.
Um requisito de conformidade dita que todas as operações de acesso a dados (leituras, escritas, consultas) devem ser auditadas.
Habilitar Configurações de Diagnóstico na conta Cosmos DB e encaminhar a categoria de log `DataPlaneRequests` para um Log Analytics workspace ou Storage Account.
Por quê: O log `DataPlaneRequests` fornece informações detalhadas sobre cada operação de dados, incluindo o tipo de operação, IP do cliente e recurso acessado, o que é essencial para auditoria de segurança.
Um cliente não confiável (por exemplo, um aplicativo móvel) precisa de acesso temporário e restrito a recursos específicos do Cosmos DB (por exemplo, apenas documentos em sua própria partição).
Implementar um serviço de camada intermediária confiável que autentica o usuário e, em seguida, usa uma chave mestra para gerar e retornar um token de recurso de curta duração e com escopo de permissão para o cliente.
Por quê: Este é o padrão mais seguro para acesso do lado do cliente, pois evita expor chaves mestras e oferece controle de acesso temporário e granular.