Microsoft AZ-204: Azure Cosmos DB — Guia de estudos

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Developer Associate AZ-204 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Azure Cosmos DB é um banco de dados multimodelo, totalmente gerenciado e distribuído globalmente, projetado para aplicações de baixa latência e elasticamente escaláveis. Ele expõe múltiplas APIs sobre um mecanismo comum de armazenamento e replicação particionado, fornece cinco níveis de consistência ajustáveis e oferece SLAs abrangentes para disponibilidade, latência, throughput e consistência. Os dados são organizados em contas, bancos de dados e contêineres (ou coleções/tabelas/grafos, dependendo da API). Os contêineres são particionados horizontalmente e escalados por uma chave de partição, e todas as operações são medidas em Request Units (RUs), uma moeda normalizada que abstrai CPU, IOPS e memória.

APIs e Programabilidade

O Cosmos DB suporta várias APIs compatíveis com o protocolo de rede (wire-compatible) para que você possa usar SDKs e drivers nativos sem reescrever seu modelo de dados:

API SQL (Core): A opção padrão recomendada para novas cargas de trabalho. Armazena documentos JSON com consultas ricas semelhantes a SQL (SELECT, WHERE, ORDER BY, JOIN dentro de um documento, agregações) e UDFs determinísticas para predicados/projeções computadas. A lógica de negócios do lado do servidor é executada como stored procedures e gatilhos (triggers) pre/post em JavaScript dentro de uma única partição lógica, permitindo transações ACID sobre múltiplos itens que compartilham a chave de partição. O TransactionalBatch fornece operações de múltiplos itens em uma partição. Leituras de ponto (id + chave de partição) são as mais eficientes em termos de RUs. Crie um cliente .NET com um código como: new CosmosClient(endpoint, key).
API para MongoDB: Compatível com o protocolo de rede do MongoDB, permitindo o uso de drivers e ferramentas padrão do MongoDB (por exemplo, mongodump/mongorestore para migrações). Você pode usar recursos do MongoDB com o respaldo da distribuição, do autoescalonamento e dos SLAs do Cosmos DB. Transações de múltiplos documentos são suportadas dentro da mesma partição lógica; para atomicidade estrita por usuário, use uma coleção não fragmentada (unsharded) ou fragmente (shard) por uma propriedade como username para que os documentos relacionados compartilhem uma partição.
API para Cassandra: Compatível com drivers Apache Cassandra e CQL. Ideal para padrões de acesso de colunas largas (wide-column) e séries temporais. Você obtém distribuição global automática e escalonamento baseado em RUs em vez de gerenciamento de nós.
API para Gremlin: Modelo de grafo de propriedades com consultas e travessias (traversals) do TinkerPop Gremlin. O particionamento é essencial para distribuir vértices e arestas para travessias escaláveis.
API de Tabela: Chave-valor com SDKs e semântica compatíveis com o Azure Table Storage, mas com o respaldo da distribuição global, do throughput de RUs e dos índices de menor latência do Cosmos DB.

Operações comuns de SDK entre as APIs incluem CRUD, concorrência otimista com ETags, upserts, scripts do lado do servidor (stored procedures, triggers) e UDFs (API SQL). As consultas são parametrizadas para reduzir RUs e melhorar a segurança. Operações em massa (bulk) e APIs de streaming minimizam a sobrecarga do cliente e os custos de RU para ingestão de alto throughput.

Consistência, Indexação e Semântica de Consulta

O Cosmos DB oferece cinco níveis de consistência bem definidos por conta (que podem ser sobrescritos por requisição em muitos SDKs):

Strong (Forte): Linearizabilidade — as leituras veem a escrita confirmada (committed) mais recente globalmente. Maximiza a exatidão (correctness), limita a latência de escrita e a flexibilidade regional, e não está disponível com escritas em múltiplas regiões habilitadas.
Bounded Staleness (Obsolescência Limitada): As leituras ficam atrasadas em relação às escritas em no máximo K versões ou um tempo T. Garante a ordenação monotônica de leitura e escrita; é um bom trade-off para leituras distribuídas globalmente que toleram um atraso limitado.
Session (Sessão) (padrão): Por sessão, garante leitura das próprias escritas (read-your-writes), escrita segue leitura (write-follows-reads) e leituras monotônicas. Cada cliente mantém um token de sessão; compartilhá-lo entre nós (por exemplo, através das opções de requisição no SDK) preserva a garantia de leitura das próprias escritas entre esses nós.
Consistent Prefix (Prefixo Consistente): As leituras nunca observam escritas fora de ordem, mas podem ver um prefixo do log.
Eventual (Eventual): Maior disponibilidade e menor latência, sem garantias de ordenação.

A indexação é automática e consistente por padrão para a API SQL. Cada item e propriedade são indexados sem gerenciamento de esquema, então as escritas atualizam o índice imediatamente (modo de indexação Consistent). Você pode refinar a política de indexação para:

Excluir caminhos (paths) grandes ou com muitas escritas para diminuir os custos de RU de escrita.
Adicionar índices compostos para suportar ORDER BY eficiente em múltiplas propriedades e consultas que combinam filtros e ordenação em diferentes propriedades.
Adicionar índices espaciais para tipos GeoJSON (Point, LineString, Polygon, MultiPolygon) e consultar com funções espaciais como ST_DISTANCE, ST_WITHIN e ST_INTERSECTS. O modo de indexação também pode ser definido como None para contêineres otimizados para escrita que são lidos apenas por id/chave de partição. Diferentes APIs expõem a indexação através de seus paradigmas nativos (por exemplo, construções de driver do MongoDB e Cassandra), mas todas utilizam o mecanismo de indexação subjacente do Cosmos.

Esteja atento ao tamanho do item e à forma da consulta. A API SQL impõe um limite de tamanho de item (por exemplo, 2 MB), e consultas entre partições (cross-partition), projeções grandes e predicados complexos aumentam o consumo de RUs. Use projeções seletivas, filtros apropriados e consultas cientes da partição (partition-aware) para minimizar o custo de RUs.

Particionamento e Throughput (RUs)

O Cosmos DB separa partições lógicas e físicas:

Partições lógicas agrupam itens por um valor de chave de partição. Todos os itens que compartilham a mesma chave participam juntos de lotes transacionais e scripts do lado do servidor.
Partições físicas são gerenciadas pelo serviço e hospedam muitas partições lógicas. O throughput (RUs) e o armazenamento são distribuídos entre as partições físicas; partições lógicas “quentes” (hot partitions) podem se tornar um gargalo para o throughput de uma partição física.

Escolha uma chave de partição eficaz com alta cardinalidade e distribuição de acesso uniforme ao longo do tempo. Boas chaves se correlacionam com seu caminho de acesso principal (por exemplo, userId, deviceId, tenantId ou orderId). Evite chaves de baixa cardinalidade ou agrupadas por tempo que causam distorção (skew) (por exemplo, country, status ou day). Quando nenhuma propriedade única é adequada:

Use uma chave sintética que concatena múltiplas propriedades.
Anexe um sufixo aleatório ou com hash para distribuir a carga entre as partições, preservando a capacidade de consulta por prefixo ou mantendo uma tabela de pesquisa (lookup).
Considere chaves de partição hierárquicas para combinar múltiplas propriedades, permitindo uma melhor distribuição e consultas de prefixo eficientes.

Modelos de throughput:

Throughput provisionado: Reserve RU/s em um contêiner ou banco de dados (compartilhado pelos contêineres filhos). Desempenho previsível com estabilidade de custos. Escale manualmente ou via APIs/CLI.
Autoscale: Defina um máximo de RU/s; o Cosmos DB escala elasticamente entre 10% e 100% desse máximo com base na carga. A cobrança é feita com base na maior RU/hora utilizada; excelente para workloads variáveis e picos desconhecidos.
Serverless: Sem RU/s provisionadas; pague pelo consumo de RUs de cada operação. Ideal para desenvolvimento, workloads com picos (spiky) ou de baixo throughput sem uma linha de base (baseline) previsível.

Técnicas de otimização de RUs incluem leituras de ponto (point reads) por id+chave de partição, consultas parametrizadas, projeções seletivas, desnormalização para reduzir padrões semelhantes a JOINs e uso do change feed para visualizações derivadas em vez de consultas complexas entre múltiplos contêineres. Use ETags com If-Match para controle de concorrência para evitar novas tentativas (retries) que consomem muitas RUs. Monitore as métricas de RU e o throttling (HTTP 429) e implemente políticas de nova tentativa (retry) com jitter nos SDKs.

Distribuição Global e Feed de Alterações

A distribuição multirregional pronta para uso (turnkey) do Cosmos DB permite adicionar ou remover regiões a qualquer momento. Todas as regiões são legíveis; habilitar gravações multirregionais permite gravações simultâneas em todos os lugares com latência de leitura abaixo de 10 ms no percentil 99 em regiões próximas. Os SDKs do cliente devem ser configurados com regiões preferenciais para rotear o tráfego localmente e realizar failover de forma suave. No .NET, forneça as regiões preferenciais via CosmosClientOptions ApplicationPreferredRegions (ou o equivalente em outros SDKs). Gravações multirregionais exigem uma política de resolução de conflitos:

Última Gravação Prevalece (Last Write Wins): Use um caminho de resolução de conflitos (por exemplo, uma propriedade de timestamp ou versão). Se não especificado, o timestamp do sistema pode ser usado.
Resolução Personalizada: Use uma stored procedure de mesclagem para reconciliar conflitos de forma determinística.
Manual: Inspecione o feed de conflitos e resolva explicitamente.

O feed de alterações (change feed) fornece um log de alterações ordenado e somente de acréscimo (append-only) por chave de partição lógica. É ideal para:

Arquiteturas orientadas a eventos e CQRS (projetando documentos em visualizações otimizadas para leitura).
Pipelines downstream (ingestão em data lake, indexação de pesquisa, invalidação de cache).
Análises em tempo quase real e auditoria. Existem dois padrões principais de consumo:
Biblioteca Change Feed Processor: Processamento distribuído e tolerante a falhas que usa um contêiner de concessões (leases) para balancear partições entre os workers e escalar horizontalmente (scale out) com segurança.
Modelo de pull com FeedIterator: Itere explicitamente sobre as alterações com uma lógica de checkpointing que você controla; segmente o trabalho através do FeedRange para paralelizar. O Azure Functions oferece um gatilho do Cosmos DB que encapsula o padrão de processador para processamento serverless. Você pode começar desde o início ou a partir de “agora”, e o feed de alterações de fidelidade total captura atualizações e exclusões intermediárias para trilhas de auditoria completas. Projete seu contêiner de concessões com throughput suficiente e escolha handlers idempotentes para acomodar novas tentativas e entrega do tipo “pelo menos uma vez” (at-least-once).

Cenário de Problema Prático

O Spotify precisa fornecer um serviço de personalização globalmente disponível que ingere interações de usuários em tempo real, atualiza recomendações por usuário e serve leituras de baixa latência a partir da região mais próxima. Gravações podem ocorrer a partir de clientes móveis em todo o mundo, e as atualizações de recomendação devem ser distribuídas (fan out) para sistemas downstream.

Escolher a API SQL (Core) do Cosmos DB com gravações multirregionais

Por quê: A API Core oferece consultas ricas e programabilidade do lado do servidor. Gravações multirregionais minimizam a latência de gravação globalmente e toleram failover regional sem tempo de inatividade para gravação.

Definir uma chave de partição de alta cardinalidade e chaves hierárquicas

Abordagem: Particionar por userId; para usuários extremamente ativos, use chaves hierárquicas como [“userId”, “bucket”], onde bucket é um sufixo de hash.
Por quê: Distribui uniformemente a carga de gravação e leitura, permite atualizações transacionais por usuário e evita partições quentes (hot partitions).

Configurar o throughput de autoescalonamento nos contêineres principais

Por quê: O tráfego é diurno e impulsionado por campanhas; o autoescalonamento lida com picos de até o máximo de RU/s configurado, mantendo o custo proporcional à carga real.

Definir a consistência como Session no nível da conta

Por quê: Clientes móveis exigem leitura de suas próprias gravações (read-your-writes) para a experiência do usuário, sem as restrições de latência da consistência Strong. Tokens de sessão são transportados pelos clientes e pela camada de gateway para preservar a semântica da sessão entre os nós.

Implementar o processamento do feed de alterações com o Azure Functions e o Change Feed Processor

Abordagem: Criar um aplicativo do Functions com um gatilho do Cosmos DB vinculado ao contêiner de interações. Usar um contêiner de concessões (leases) dedicado e habilitar múltiplas instâncias para paralelismo.
Por quê: Isso fornece processamento resiliente, escalável e de baixa sobrecarga operacional (low-ops) para atualizar visualizações materializadas (por exemplo, um contêiner de recomendações) e para publicar eventos no Event Hubs para análises de streaming.

Criar um contêiner de recomendações derivado com uma política de indexação personalizada

Abordagem: Excluir da indexação propriedades grandes e com muita gravação; adicionar índices compostos para (userId, score DESC) para suportar consultas TOP-K.
Por quê: Reduz os custos de RU de gravação, ao mesmo tempo que permite buscas ordenadas eficientes para feeds personalizados.

Habilitar a distribuição global com regiões preferenciais nos SDKs

Abordagem: Adicionar regiões na América do Norte, Europa e APAC. Configurar CosmosClientOptions com ApplicationPreferredRegions com base na região de implantação do aplicativo.
Por quê: Garante que as leituras sejam servidas localmente para uma latência abaixo de 10 ms e que o failover seja transparente.

Configurar a resolução de conflitos e a observabilidade

Abordagem: Usar Last Write Wins com um relógio lógico gerado pelo servidor (propriedade de versão) para atualizações idempotentes e rotear conflitos para uma fila de monitoramento para casos de borda raros.
Por quê: Garante a convergência determinística sob gravações multirregionais concorrentes e fornece visibilidade operacional.

Essa arquitetura oferece leituras e gravações de baixa latência globalmente, processamento de eventos resiliente por meio do feed de alterações, autoescalonamento com custo-benefício e semântica de consistência robusta, adequada para cargas de trabalho de personalização.

← Azure Storage e Blob Storage · Todos os domínios · Soluções de Contêineres do Azure →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →