db-reservas resuelve muy bien el problema de que una plaza no se venda dos veces, pero es una mala casa para el catálogo de tarifas de Contoso Airlines. Una tarifa "Flex Business Larga Distancia" tiene condiciones de cambio, equipaje permitido, acumulación de puntos, penalizaciones por tramo y restricciones por temporada; una tarifa "Básica Nacional" tiene cuatro campos. Normalizar eso significa veinte tablas y consultas con diez uniones para responder algo tan simple como "dame esta tarifa entera". Además, el catálogo se lee miles de veces por minuto desde la web y desde la API de Disponibilidad, se escribe dos veces al día, y hay clientes en Europa y en América esperando la respuesta.

Ese es exactamente el terreno de Azure Cosmos DB: una base de datos NoSQL distribuida globalmente, con latencia garantizada de un dígito en milisegundos, escalado elástico y esquema flexible. Esta lección la despliega para el catálogo de tarifas y los perfiles de pasajero, y se detiene con calma en las dos decisiones que la gente toma mal: la clave de partición y el nivel de consistencia.

Aviso de coste importante: Cosmos DB puede ser barato o carísimo según cómo se configure. Un contenedor con 400 RU/s aprovisionadas cuesta unos 23 € al mes y factura aunque nadie lo use; activar escrituras multirregión multiplica el coste por región. Para aprender, usa el nivel gratuito (1000 RU/s y 25 GB sin coste, una cuenta por suscripción) o el modo sin servidor, y elimina la cuenta al terminar.

1. Qué problema resuelve que no resuelve una base relacional
2. Las API disponibles y cuál elegir
3. Modelo de recursos: cuenta, base de datos, contenedor y elemento
4. La clave de partición: la decisión más irreversible
5. Unidades de solicitud (RU/s) y modelos de capacidad
6. Los cinco niveles de consistencia
7. Distribución global y escrituras multirregión
8. Despliegue con Azure CLI
9. Documentos de tarifas: inserción y consulta
10. Política de indexación y tiempo de vida
11. La fuente de cambios como base de la integración
12. Copias de seguridad continuas y control del gasto
13. Errores Comunes y Consejos
14. Ejercicios
15. Conclusión

Azure SQL Database escala verticalmente: si necesitas más, subes de nivel, hasta que llegas al techo de la máquina. Cosmos DB escala horizontalmente y de forma transparente: reparte los datos entre particiones físicas que el servicio añade solo, sin que tú hagas nada, y puede replicar esas particiones en tantas regiones como quieras con un clic. Las diferencias que importan al decidir:

La conclusión no es que uno sea mejor: es que responden preguntas distintas. Si tu consulta cruza entidades que nadie previó, quieres SQL. Si tu consulta es "dame este documento por su clave, rápido, desde cualquier continente, y que no me importe cuántos millones haya", quieres Cosmos DB.

Cosmos DB es un motor con varias caras compatibles con protocolos existentes. La API se elige al crear la cuenta y no se puede cambiar después:

Contoso elige la API NoSQL por tres motivos concretos: es un desarrollo nuevo sin nada que migrar, las funcionalidades nuevas llegan siempre primero a esta API, y el equipo de Diego Salas ya escribe consultas SQL, así que la sintaxis les resulta familiar desde el primer día.

La jerarquía tiene cuatro niveles y cada uno decide algo distinto:

• Cuenta (cosmos-contoso-tarifas-pro): el límite de la API, de las regiones, de la consistencia predeterminada y de las claves de acceso. Es el recurso que aparece en el portal y en la factura.
• Base de datos (catalogo): agrupación lógica; puede tener rendimiento compartido por todos sus contenedores.
• Contenedor (tarifas, perfiles): la unidad real de escalado y distribución. Aquí se define la clave de partición, el rendimiento y la política de indexación. Es el equivalente conceptual a una tabla, pero sin esquema.
• Elemento: el documento JSON. Cada uno tiene un id obligatorio y su valor de clave de partición; la pareja id + clave de partición identifica de forma única un elemento.

Cosmos DB agrupa los elementos que comparten valor de clave de partición en una partición lógica, y reparte esas particiones lógicas entre particiones físicas de hasta 50 GB y 10.000 RU/s. Toda la escalabilidad depende de que ese reparto sea uniforme. Una buena clave de partición cumple tres cosas a la vez:

1. Cardinalidad alta: muchos valores distintos, para que haya muchas particiones lógicas.
2. Reparto uniforme de peticiones y datos, sin valores mucho más activos que otros.
3. Aparece en la mayoría de las consultas, para que estas se resuelvan en una sola partición.

Aplicado al catálogo de tarifas de Contoso:

El caso de /fecha merece detenerse, porque es el error más repetido del sector. Parece razonable: las tarifas se consultan por fecha de vuelo. Pero el 90 % de las consultas se refieren a los próximos 30 días, así que un puñado de particiones lógicas recibe casi todo el tráfico mientras el resto duerme. Ese desequilibrio se llama partición caliente: aunque el contenedor tenga 10.000 RU/s, cada partición física solo puede usar su parte, así que empiezan a llegar errores de límite excedido (código 429) con el contenedor globalmente ocioso.

Y por qué es irreversible: la clave de partición de un contenedor no se puede cambiar. Corregirla obliga a crear un contenedor nuevo y migrar todos los datos, con la aplicación escribiendo en los dos durante la transición. Por eso esta decisión se toma escribiendo antes las consultas, no después.

Si ninguna propiedad sirve por sí sola, se usa una clave sintética: concatenar dos campos ("BCN-CDG_2026-07") para subir la cardinalidad manteniendo el filtro habitual.

Una unidad de solicitud (RU) es la moneda de Cosmos DB: normaliza el coste de CPU, memoria y E/S de cada operación. La referencia es que leer por id un documento de 1 KB cuesta 1 RU. Una escritura de ese mismo documento cuesta unas 5 RU, y una consulta que recorre muchos documentos puede costar cientos. Lo que contratas es un caudal: RU por segundo.

Lo mejor de este modelo es que cada respuesta te dice lo que ha costado, en la cabecera x-ms-request-charge. Es la forma de optimizar sin adivinar:

Esas dos cifras cuentan toda la historia: la primera consulta lleva la clave de partición y se resuelve en una sola; la segunda es una consulta entre particiones y cuesta 17 veces más. Para estimar el caudal necesario basta multiplicar: si Contoso espera 900 lecturas por segundo de 3 RU cada una, necesita unas 2700 RU/s más margen para los picos.

Aquí es donde el teorema CAP de la lección 03-01 se vuelve una casilla de configuración. Cosmos DB ofrece cinco niveles, de más estricto a más relajado, y se pueden relajar por petición desde el SDK:

Aplicado al ejemplo del inventario de plazas: con consistencia eventual, dos clientes en Madrid y en Bogotá podrían leer a la vez que quedan 2 plazas cuando en realidad ya solo hay 1, y venderías un asiento inexistente. Por eso Contoso no pone el inventario de plazas en Cosmos DB: vive en db-reservas con su restricción CHECK, como se decidió en 03-01. Lo que sí va a Cosmos DB tolera perfectamente la consistencia de sesión, que es el nivel predeterminado y el mejor equilibrio para el 90 % de las aplicaciones.

Añadir una región a una cuenta de Cosmos DB replica todos los datos y permite que los clientes lean del punto más cercano. Hay dos configuraciones muy distintas en coste y en consecuencias:

• Escrituras en una sola región: una región es la de escritura y las demás son de lectura. Sencillo, sin conflictos posibles y con la mitad de coste.
• Escrituras multirregión: se puede escribir en cualquier región, con latencia de escritura mínima en todas. El precio es doble: cuesta más por RU y aparecen conflictos cuando dos regiones modifican el mismo documento, que hay que resolver (por defecto gana la última escritura según una marca de tiempo, o con un procedimiento propio).

La decisión de Contoso es coherente con todo el curso: escritura solo en West Europe, lectura también en North Europe. Las tarifas las publica un único equipo desde Barcelona, así que las escrituras multirregión resolverían un problema inexistente a cambio de duplicar la factura y añadir conflictos.

Para el entorno de desarrollo, la cuenta se crea con --enable-free-tier true (solo una por suscripción) o en modo sin servidor con --capabilities EnableServerless, que no admite autoescalado pero solo cobra lo consumido. Fíjate en que --partition-key-path es el único parámetro de este script que no podrás cambiar después.

Así es un documento de tarifa. Todo lo que en un modelo relacional serían cinco tablas está aquí anidado y se lee de una vez:

Ese mismo documento como filas relacionales exigiría tablas de tarifas, condiciones, equipaje y temporadas, más tres uniones para reconstruirlo. Aquí es una lectura por clave: 1 RU.

Y las consultas típicas, en el dialecto de la API NoSQL, donde c es cada documento del contenedor:

El JOIN de la segunda consulta no une contenedores —eso no existe en Cosmos DB—, sino que despliega un array dentro del propio documento. Es la diferencia conceptual que más cuesta a quien viene del mundo relacional.

Por defecto, Cosmos DB indexa todas las propiedades de todos los documentos. Es cómodo al empezar y caro cuando el volumen crece: cada índice consume RU en cada escritura. En un contenedor con escrituras intensas, afinar la política es de los ajustes que más dinero ahorran.

Se indexa lo que aparece en cláusulas WHERE u ORDER BY y se excluye lo que solo se lee como parte del documento: las condiciones y las temporadas se devuelven al leer la tarifa, pero nadie filtra por ellas. En los perfiles de pasajero, Contoso aplica el mismo criterio y baja el coste de escritura casi a la mitad.

El tiempo de vida (TTL) borra automáticamente los documentos caducados sin consumir RU de tu contenedor, y es perfecto para datos con vencimiento natural:

Un documento concreto puede sobrescribir ese valor con su propia propiedad ttl, o desactivarlo con ttl: -1.

La fuente de cambios (change feed) es un registro ordenado y persistente de todas las creaciones y modificaciones de un contenedor, que se puede leer en cualquier momento desde el principio o desde un punto guardado. Convierte a Cosmos DB en el punto de partida de arquitecturas basadas en eventos, sin colas adicionales.

En Contoso resuelve tres necesidades reales con el mismo mecanismo: cuando cambia una tarifa, invalidar la caché de la web y avisar al motor de precios; cuando se crea un perfil de pasajero, dispararle el correo de bienvenida; y copiar cada cambio al lago de datos para la analítica del módulo 3.6. Lo habitual es consumirla con un desencadenador de Azure Functions, que gestiona por ti el reparto entre instancias y el punto de lectura guardado; se monta en la lección 06-03. La fuente de cambios no registra los borrados: cuando importa saberlos, se hace un borrado lógico marcando el documento y dejando que el TTL lo elimine después.

Cosmos DB ofrece dos modos de copia de seguridad, y el elegido en el despliegue del apartado 8 es el bueno:

• Periódicas: instantáneas cada cierto intervalo, con restauración a través de un ticket de soporte. Es el modo antiguo.
• Continuas (--backup-policy-type Continuous): restauración a cualquier segundo de los últimos 7 o 30 días, ejecutada por ti mismo y a una cuenta nueva, igual que la restauración a un momento dado de Azure SQL Database.

Sobre el gasto, tres reglas que evitan sustos: el rendimiento aprovisionado factura aunque nadie lea nada, así que un contenedor de pruebas olvidado cuesta dinero cada hora; cada región añadida multiplica el coste de rendimiento y de almacenamiento; y el mínimo de un contenedor con autoescalado es el 10 % del máximo, de modo que fijar 40.000 RU/s de techo implica pagar como mínimo 4000 RU/s siempre. Para dejar de pagar, az cosmosdb delete --name $CUENTA --resource-group $RG --yes, porque una cuenta de Cosmos DB no se puede pausar.

• Elegir la clave de partición sin escribir antes las consultas. Es irreversible: corregirla obliga a crear otro contenedor y migrar todo. Escribe primero las cinco consultas más frecuentes.
• Usar la fecha como clave de partición. Concentra el tráfico reciente en pocas particiones y provoca errores 429 con el contenedor casi ocioso.
• Consultar sin la clave de partición. Una consulta entre particiones puede costar 20 veces más. Si es inevitable y frecuente, replantea el modelo o crea una vista materializada con la fuente de cambios.
• Dejar la indexación predeterminada en contenedores con muchas escrituras. Indexarlo todo encarece cada escritura; excluye lo que nunca se filtra.
• Poner el inventario de plazas en Cosmos DB con consistencia eventual. Se venden asientos que no existen. Ese dato pertenece a la base relacional.
• Activar escrituras multirregión "por si acaso". Duplica el coste y trae conflictos que hay que resolver. Solo tiene sentido si hay usuarios escribiendo desde varios continentes.
• Consejo: mira siempre el cargo de RU (x-ms-request-charge) al desarrollar una consulta nueva. Optimizar con esa cifra delante convierte la afinación en algo medible.
• Consejo: para aprender, activa el nivel gratuito o el modo sin servidor. La diferencia entre una factura de 0 € y una de 300 € es una casilla marcada al crear la cuenta.

Contoso añade un contenedor embarques con un documento por pasajero embarcado: unos 90 millones al año, escritos en el momento del escaneo y consultados casi siempre como "todos los embarques de un vuelo concreto en una fecha".

1. Evalúa como clave de partición /aeropuerto, /fechaEmbarque, /numeroVuelo y una clave sintética /vueloFecha ("CT1042_2026-07-14"), aplicando los tres criterios.
2. Elige una y justifícala.
3. ¿Qué política de TTL propondrías y por qué?

Para cada dato, elige nivel de consistencia y justifica:

1. Precio de una tarifa publicada, que cambia dos veces al día.
2. Preferencia de asiento del pasajero, que él mismo acaba de guardar en la web.
3. Cupo restante de plazas promocionales de una campaña, con tolerancia de unos segundos.
4. Historial de estados de una tarifa, donde el orden importa pero el retraso no.

Un contenedor perfiles de 5 millones de documentos tiene 20.000 RU/s aprovisionadas fijas, indexación predeterminada, clave de partición /pais y una consulta muy frecuente: SELECT * FROM c WHERE c.correo = @correo.

1. Identifica los tres problemas.
2. Propón una corrección para cada uno, indicando cuál exige recrear el contenedor.
3. ¿Qué modelo de capacidad recomendarías si el tráfico se concentra entre las 8 y las 22 h?

Solución 1:

2. /vueloFecha. Es el único candidato que cumple los tres criterios a la vez, y además convierte la consulta más frecuente en una consulta de partición única, de coste mínimo.
3. TTL de unos 400 días: la explotación operativa necesita el histórico de la temporada y del año anterior; lo más antiguo ya está en el lago de datos para analítica (lección 03-06) y mantenerlo en Cosmos DB solo añade coste de almacenamiento.

Solución 2:

1. Eventual: es el dato más tolerante del catálogo; que una réplica muestre el precio anterior durante unos segundos no tiene consecuencias, y es el nivel más barato y rápido.
2. Sesión: el requisito es exactamente "que el cliente vea sus propias escrituras". Con eventual, el pasajero podría guardar su asiento, recargar la página y ver el anterior, que es el fallo que más tickets de soporte genera.
3. Obsolescencia limitada, acotada por tiempo: garantiza que el desfase no supere unos segundos, suficiente para un cupo promocional donde un pequeño exceso es asumible.
4. Prefijo coherente: no exige inmediatez, pero impide ver los estados desordenados, que es lo único que rompería la lectura del historial.

Solución 3:

1. Problemas: (a) la clave de partición /pais tiene cardinalidad bajísima y reparto pésimo —España concentraría la mayoría de los perfiles—; (b) la consulta por correo no lleva la clave de partición, así que se ejecuta contra todas las particiones y cuesta decenas de RU; (c) 20.000 RU/s aprovisionadas fijas se pagan las 24 horas, incluidas las de madrugada, y la indexación predeterminada encarece cada escritura.
2. Correcciones: cambiar la clave de partición a /correo (o /pasajeroId, si es lo que usa el resto de la aplicación), lo que obliga a crear un contenedor nuevo y migrar los datos, ya que la clave es inmutable; excluir de la indexación las propiedades que nunca se filtran; y pasar a autoescalado.
3. Autoescalado con un máximo de 20.000 RU/s: por la noche bajará hasta 2000 RU/s (el 10 % del máximo) y solo pagará el pico real de cada hora. Aunque la RU de autoescalado cuesta un 50 % más, con un perfil de 14 horas activas de 24 el ahorro es claro.

Ya tienes las dos mitades del corazón de datos de Contoso Airlines: lo transaccional en Azure SQL Database y lo flexible y global en Azure Cosmos DB. Sabes qué problema resuelve que no resuelve una base relacional —escalado horizontal transparente, latencia garantizada de un dígito en milisegundos y distribución global— y a qué renuncias a cambio: uniones entre entidades y transacciones más allá de una partición. Conoces las cinco API y por qué en un proyecto nuevo se elige la de NoSQL, y manejas la jerarquía de cuenta, base de datos, contenedor y elemento sabiendo que el contenedor es donde se decide todo lo importante.

Sobre todo, has trabajado a fondo la decisión que marca el destino de un proyecto: la clave de partición. Sabes sus tres criterios, por qué /origenDestino funciona para el catálogo de tarifas y por qué /fecha crea una partición caliente que dispara errores 429 con el contenedor ocioso, qué es una clave sintética y por qué corregirse cuesta una migración completa. Entiendes las unidades de solicitud, los cuatro modelos de capacidad y cómo leer el cargo de RU de cada consulta para optimizar con datos y no con intuiciones. Has elegido nivel de consistencia dato a dato con la tabla de los cinco niveles, entendiendo por qué el inventario de plazas se queda en la base relacional y por qué el nivel de sesión es el equilibrio correcto para casi todo. Has desplegado cosmos-contoso-tarifas-pro con lectura en North Europe y escritura solo en West Europe, has insertado y consultado documentos de tarifas viendo la diferencia de coste entre una consulta de partición única y una entre particiones, has afinado la política de indexación, aplicado TTL y conocido la fuente de cambios que alimentará las integraciones del módulo 6, además de las copias continuas y las tres reglas que evitan sustos en la factura.

En la siguiente lección bajamos de las decisiones de diseño a un problema mucho más terrenal y muy frecuente en cualquier migración real. El portal de contenidos y el blog corporativo de Contoso son un WordPress que lleva ocho años funcionando sobre un MySQL instalado en un servidor del sótano de Barcelona, con su versión antigua, sus copias de seguridad en un disco USB y nadie que se atreva a tocarlo. Nadie va a reescribirlo. En Azure Database for MySQL verás cómo se lleva a la nube tal cual: servidor flexible, niveles de cómputo, acceso privado desde la red virtual, parámetros del servidor, réplicas de lectura y, sobre todo, la migración desde el servidor propio con mysqldump o con el servicio de migración de bases de datos, con su checklist de verificación y su ventana de mantenimiento acordada.