Microsoft Azure Cosmos DB Developer Specialty
Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen DP-420. Lee de arriba a abajo o salta a una sección.
Existe una relación de uno a pocos donde los datos relacionados son acotados, pequeños y se leen con frecuencia juntos.
Incrustar los datos relacionados como un objeto o matriz anidada dentro del documento principal.
Por qué: Optimiza el rendimiento de lectura al recuperar todos los datos necesarios en una única lectura de punto, minimizando el costo de RU y la latencia. Evita uniones del lado del cliente.
Una relación de uno a muchos donde el lado "muchos" crece ilimitadamente o se actualiza independientemente del lado "uno".
Almacenar los elementos relacionados como documentos separados y usar el ID del documento padre como referencia.
Por qué: Evita que los documentos excedan el límite de tamaño de 2 MB y evita altos costos de RU para actualizaciones en grandes matrices incrustadas.
Un documento contiene una matriz que puede crecer ilimitadamente con el tiempo, lo que arriesga el límite de tamaño de documento de 2 MB (por ejemplo, registros de eventos, comentarios).
Dividir la matriz entre múltiples documentos de "cubeta". Cuando una cubeta alcanza un umbral de tamaño/elemento, crear una nueva.
Por qué: Mantiene los tamaños de los documentos individuales manejables mientras se mantiene el agrupamiento lógico de los datos relacionados.
Modelar una relación de muchos a muchos, como estudiantes y cursos, o artículos y etiquetas.
Para relaciones acotadas, duplicar los datos de la relación en ambos lados (por ejemplo, incrustar IDs de cursos en el documento del estudiante, IDs de estudiantes en el documento del curso). Para relaciones no acotadas, usar un contenedor de documentos de "unión" o "borde" separado.
Por qué: La desnormalización optimiza ambas direcciones de consulta (estudiantes en el curso, cursos para el estudiante) sin requerir uniones. Un contenedor de unión es para casos no acotados.
Modelar datos jerárquicos (por ejemplo, organigrama, categorías de productos) y necesitar consultar todos los descendientes de un nodo.
Almacenar una matriz de todos los IDs o nombres de ancestros (la ruta) en cada documento.
Por qué: Permite consultas eficientes de subárboles con un único filtro `ARRAY_CONTAINS`, evitando búsquedas recursivas costosas.
Un documento tiene una matriz ilimitada (por ejemplo, comentarios de blog), pero la consulta más común solo necesita los N elementos más recientes.
Incrustar un subconjunto de elementos recientes en el documento principal y almacenar todos los elementos como documentos referenciados separados.
Por qué: Optimiza la ruta de lectura principal para el rendimiento y el costo, al mismo tiempo que permite el acceso al conjunto de datos completo cuando sea necesario.
Almacenar una secuencia de eventos inmutables para una entidad y necesitar consultar el estado actual o agregados analíticos.
Almacenar eventos en un único contenedor particionado por el ID de la entidad. Usar Change Feed o Synapse Link para calcular y almacenar vistas materializadas o agregados.
Por qué: Proporciona una pista de auditoría completa y desacopla el modelo de escritura de varios modelos de lectura, ofreciendo alta flexibilidad.
Necesidad de preservar el estado de los datos relacionados en un momento específico (por ejemplo, la dirección de un cliente en un pedido).
Incrustar una copia (instantánea) de los datos relacionados en el documento, en lugar de referenciarlos.
Por qué: Garantiza la precisión histórica al desacoplar el documento de futuros cambios en los datos referenciados.
Ingesta de datos de series temporales de alta frecuencia (por ejemplo, lecturas de sensores IoT) y consulta por dispositivo en rangos de tiempo.
Usar el ID del dispositivo como clave de partición. Agrupar las lecturas en documentos por cubo de tiempo (por ejemplo, por hora o por minuto) en lugar de un documento por lectura.
Por qué: Reduce drásticamente el recuento de documentos y las RUs de escritura, mientras co-localiza datos para consultas eficientes de rangos de tiempo dentro de una partición.
Necesidad de realizar múltiples operaciones de creación, actualización o eliminación como una única transacción atómica.
Usar la característica TransactionalBatch del SDK. Todas las operaciones deben apuntar a la misma clave de partición lógica.
Por qué: Proporciona garantías ACID para hasta 100 operaciones dentro de una sola partición, asegurando que todas las operaciones se realicen con éxito o todas fallen juntas.
Los documentos deben eliminarse automáticamente de un contenedor después de un período específico (por ejemplo, 30 días).
Habilitar Time to Live (TTL) en el contenedor y establecer el valor `ttl` predeterminado en segundos (por ejemplo, 2592000 para 30 días). Un `ttl` de -1 en un documento individual anula el valor predeterminado y evita la expiración.
Por qué: TTL es una característica sin costo que utiliza RUs sobrantes para realizar eliminaciones en segundo plano, proporcionando una forma eficiente y sin intervención para gestionar el ciclo de vida de los datos.
Necesidad de almacenar objetos binarios grandes (imágenes, videos, documentos > 2 MB) asociados con metadatos de Cosmos DB.
Almacenar el objeto binario en Azure Blob Storage. Almacenar el URI del blob en el documento de Cosmos DB junto con los metadatos.
Por qué: Cosmos DB está optimizado para metadatos estructurados y tiene un límite de documentos de 2 MB. Blob Storage es un servicio rentable y escalable para el almacenamiento de objetos grandes.
Los mismos datos deben ser consultados por diferentes propiedades, lo que lleva a consultas entre particiones ineficientes (por ejemplo, consultar pedidos por cliente, luego por producto).
Usar Change Feed para poblar un segundo contenedor (una vista materializada) con los mismos datos, pero particionados por la propiedad de consulta secundaria.
Por qué: Mueve el cómputo del tiempo de lectura al tiempo de escritura, permitiendo consultas eficientes de una sola partición para múltiples patrones de acceso.
Necesidad de ejecutar consultas analíticas complejas (agregaciones, uniones) sobre datos operativos en vivo sin afectar la carga de trabajo transaccional.
Habilitar Azure Synapse Link en el contenedor de Cosmos DB. Ejecutar consultas analíticas contra el almacén analítico del contenedor usando Synapse serverless SQL o pools de Spark.
Por qué: Proporciona una solución HTAP nativa de la nube sin ETL. Las consultas contra el almacén analítico columnar no consumen RUs transaccionales y son de alto rendimiento.
Necesidad de activar acciones posteriores de forma escalable, fiable y sin servidor en respuesta a cambios en los datos.
Usar una Azure Function con el disparador de Cosmos DB. El disparador aprovecha automáticamente la biblioteca Change Feed Processor.
Por qué: Este es el patrón recomendado para arquitecturas dirigidas por eventos. Proporciona escalado automático, puntos de control y gestión de concesiones de partición.
Una operación debe actualizar atómicamente la base de datos y publicar un mensaje en un sistema de mensajería (por ejemplo, Service Bus, Event Hubs).
Realizar la escritura en la base de datos. Usar un procesador Change Feed para leer de forma fiable el cambio confirmado y publicar el mensaje correspondiente, con lógica de reintento.
Por qué: Evita escrituras dobles poco fiables y la necesidad de transacciones distribuidas. Change Feed actúa como una bandeja de salida duradera, garantizando la entrega eventual del mensaje.
Elegir una clave de partición para un nuevo contenedor para asegurar el rendimiento y la escalabilidad.
Seleccionar una propiedad con alta cardinalidad que esté presente en la mayoría, si no en todas, las operaciones de lectura de punto y consulta.
Por qué: Alinear la clave de partición con el filtro de consulta más común asegura que la mayoría de las operaciones se dirijan a una única partición lógica, que es el patrón de acceso más eficiente.
Un único valor de clave de partición recibe un volumen desproporcionadamente alto de solicitudes, causando estrangulamiento (una "partición caliente").
Crear una clave de partición sintética concatenando la clave original con un sufijo aleatorio u otra propiedad de alta cardinalidad (por ejemplo, `userId + "-" + random(1-10)`).
Por qué: Distribuye la carga de escritura y lectura para una única entidad lógica a través de múltiples particiones físicas, mitigando el estrangulamiento.
Los datos necesitan ser particionados por múltiples niveles (por ejemplo, inquilino, luego año, luego mes) para evitar particiones grandes y soportar consultas multi-nivel.
Configurar una clave de partición jerárquica con una matriz ordenada de rutas, como `["/tenantId", "/year"]`.
Por qué: Permite la sub-partición para evitar el límite de partición lógica de 20 GB y habilita un enrutamiento más eficiente para consultas que filtran por la jerarquía.
Una aplicación distribuida globalmente con escrituras multirregión habilitadas necesita manejar actualizaciones concurrentes al mismo documento.
Para sobrescrituras simples, usar Last-Writer-Wins (LWW). Para operaciones que requieren lógica de fusión (por ejemplo, incrementar un contador, actualizar inventario), usar una política de resolución de conflictos personalizada con un procedimiento almacenado de fusión.
Por qué: La lógica de fusión personalizada evita la pérdida de datos (por ejemplo, un incremento perdido) que ocurriría con LWW, asegurando la integridad de los datos para operaciones comerciales críticas.
Equilibrar la latencia de lectura, la disponibilidad y la consistencia de los datos para una aplicación distribuida globalmente.
Por defecto, usar consistencia de Sesión para un buen equilibrio y "leer tus propias escrituras". Usar "Bounded Staleness" (obsolescencia limitada) para un retraso de lectura predecible. Anular operaciones de escritura/lectura críticas específicas a consistencia Fuerte según sea necesario.
Por qué: Sesión es el nivel más utilizado, proporcionando baja latencia y fuertes garantías dentro de una sesión de cliente. Anular por solicitud permite flexibilidad.
Las operaciones de escritura están consumiendo RUs excesivas, y solo un pequeño subconjunto de propiedades de documentos se utiliza en filtros de consulta.
Cambiar de la política de indexación predeterminada a una política personalizada. Incluir explícitamente rutas para las propiedades consultadas y excluir todas las demás rutas (`"/*"` en `excludedPaths`).
Por qué: Cada propiedad indexada incurre en un costo de RU en las escrituras. Excluir propiedades no utilizadas puede reducir significativamente el consumo de RUs de escritura y el tamaño del almacenamiento del índice.
Una consulta frecuente filtra por una propiedad y ordena por otra (por ejemplo, `WHERE c.status = "active" ORDER BY c.timestamp DESC`).
Crear un índice compuesto en las propiedades en el orden en que aparecen en la consulta: `(status ASC, timestamp DESC)`.
Por qué: Permite al motor de consultas servir el resultado filtrado y ordenado directamente desde el índice, evitando una costosa operación de ordenación en memoria y reduciendo drásticamente la carga de RU.
Una consulta recupera documentos grandes, pero la aplicación solo necesita una o dos propiedades pequeñas de ellos.
Usar proyección de consulta para seleccionar solo las propiedades requeridas (por ejemplo, `SELECT c.id, c.name FROM c`) en lugar de `SELECT *`.
Por qué: Reduce el costo de RU al disminuir el tamaño de la carga útil de datos transferida desde el motor de la base de datos al cliente.
Una aplicación consulta frecuentemente las actualizaciones de documentos, pero los datos cambian con poca frecuencia, lo que conlleva altos costos de RU para las lecturas.
Almacenar el ETag de la última lectura. En lecturas posteriores, enviar el ETag en un encabezado `If-None-Match`.
Por qué: Si el documento no ha cambiado, Cosmos DB devuelve un estado 304 Not Modified con un cargo de RU mínimo (típicamente ~1 RU), ahorrando costos y ancho de banda.
Una carga de trabajo tiene patrones de tráfico variables o impredecibles, con picos y valles significativos.
Configurar el rendimiento de escalado automático en la base de datos o el contenedor. Establecer el máximo de RU/s necesario para la carga máxima.
Por qué: Escala automáticamente el rendimiento entre el 10% del máximo y el máximo de RU/s en función del uso, optimizando los costos al no pagar por la capacidad aprovisionada inactiva.
Una carga de trabajo es para desarrollo, pruebas o una aplicación de bajo tráfico con largos períodos de inactividad.
Usar el modo de capacidad Serverless para la cuenta de Cosmos DB.
Por qué: Solo pagas por las RUs consumidas por operación, sin capacidad mínima aprovisionada. Esta es la opción más rentable para cargas de trabajo esporádicas.
Necesidad de ingerir o modificar un gran número de documentos (miles a millones) lo más rápido posible.
Usar la característica de soporte masivo del SDK (por ejemplo, `AllowBulkExecution = true` en .NET SDK v3).
Por qué: El SDK optimiza para un alto rendimiento al agrupar operaciones por lotes, gestionar la concurrencia y manejar internamente los reintentos/estrangulamiento, superando con creces las operaciones secuenciales.
Un procedimiento almacenado que procesa un gran lote de documentos está agotando el tiempo de espera.
Implementar ejecución acotada. El procedimiento almacenado debe verificar si se está acercando al límite de ejecución de 5 segundos y, si es así, devolver un token de continuación al cliente. El cliente luego vuelve a invocar el procedimiento con el token para reanudar el procesamiento.
Por qué: Los procedimientos almacenados tienen un límite de tiempo de ejecución estricto. Un patrón de continuación es la forma estándar de manejar la lógica de servidor de larga duración y múltiples pasos.
Una aplicación de misión crítica requiere alta disponibilidad con una pérdida de datos mínima (RPO) y un tiempo de recuperación rápido (RTO) en caso de una interrupción regional.
Configurar la cuenta de Cosmos DB con múltiples regiones de escritura y habilitar la conmutación por error automática.
Por qué: Proporciona el RPO y RTO más bajos. Los datos se replican entre regiones, y en caso de una interrupción, Cosmos DB promueve automáticamente una región secundaria para que sea la nueva región de escritura primaria.
Necesidad de poder recuperarse de la eliminación o corrupción accidental de datos restaurando la base de datos a un punto específico en el tiempo.
Habilitar el modo de copia de seguridad continua en la cuenta de Cosmos DB.
Por qué: La copia de seguridad continua permite restaurar a cualquier punto en el tiempo (hasta el segundo) dentro del período de retención (7 o 30 días). La operación de restauración crea una nueva cuenta.
Un requisito de cumplimiento normativo exige que las claves de cifrado de datos sean gestionadas y controladas por el cliente.
Configurar la cuenta de Cosmos DB con claves gestionadas por el cliente (CMK), utilizando una clave de un Azure Key Vault.
Por qué: Proporciona una capa adicional de seguridad donde usted controla el ciclo de vida de la clave (incluyendo la rotación y revocación) para el cifrado en reposo.
Necesidad de otorgar a una aplicación o usuario acceso a datos basado en identidad y con granularidad fina, siguiendo el principio de mínimo privilegio.
Usar la integración de Azure AD y asignar un rol incorporado (por ejemplo, Cosmos DB Built-in Data Reader) o un rol RBAC personalizado, con ámbito en el contenedor o base de datos específica.
Por qué: Elimina la necesidad de gestionar y compartir claves maestras. RBAC proporciona control de acceso auditable y basado en identidad.
Una cuenta de Cosmos DB debe ser accesible solo desde dentro de una Azure Virtual Network (VNet) específica, sin tráfico a través de internet público.
Crear un Private Endpoint para la cuenta de Cosmos DB en la VNet y deshabilitar el acceso a la red pública en la configuración del firewall.
Por qué: Los Private Endpoints proporcionan una dirección IP privada para la cuenta de Cosmos DB dentro de su VNet, asegurando que todo el tráfico fluya a través de la red troncal segura de Azure.
Diagnosticar la causa raíz de los errores de estrangulamiento HTTP 429 (Too Many Requests).
Monitorear la métrica "Consumo de RU Normalizado" en Azure Monitor. Usar los Registros de Diagnóstico (`CDBPartitionKeyRUConsumption`) para identificar qué claves de partición están consumiendo la mayor cantidad de RUs.
Por qué: El consumo normalizado de RU muestra si el rendimiento general está agotado. Los registros a nivel de partición identifican particiones "calientes", lo cual es una causa común de estrangulamiento incluso cuando el uso general es bajo.
Necesidad de monitorear y alertar sobre la latencia de las solicitudes para asegurar el cumplimiento del SLA.
Monitorear la métrica "Latencia del lado del servidor P99" en Azure Monitor. Crear una regla de alerta para cuando esta métrica exceda el umbral del SLA.
Por qué: La latencia P99 representa la peor experiencia para el 99% de las solicitudes y es en lo que se basan los SLA de Cosmos DB. Es un indicador más significativo de problemas de rendimiento que la latencia promedio.
Un requisito de cumplimiento normativo dicta que todas las operaciones de acceso a datos (lecturas, escrituras, consultas) deben ser auditadas.
Habilitar la configuración de diagnóstico en la cuenta de Cosmos DB y reenviar la categoría de registro `DataPlaneRequests` a un espacio de trabajo de Log Analytics o a una cuenta de Storage.
Por qué: El registro `DataPlaneRequests` proporciona información detallada sobre cada operación de datos, incluyendo el tipo de operación, la IP del cliente y el recurso accedido, lo cual es esencial para la auditoría de seguridad.
Un cliente no confiable (por ejemplo, una aplicación móvil) necesita acceso temporal y limitado a recursos específicos de Cosmos DB (por ejemplo, solo documentos en su propia partición).
Implementar un servicio de nivel intermedio confiable que autentique al usuario, luego use una clave maestra para generar y devolver un token de recurso de corta duración y con ámbito de permisos al cliente.
Por qué: Este es el patrón más seguro para el acceso del lado del cliente, ya que evita exponer claves maestras y proporciona un control de acceso temporal y de granularidad fina.
