Hotels and airlines deliver their offers to Nordlicht Reisen GmbH, and every partner sends different fields: room types, seasons, extras, baggage rules. A schema that covers everything doesn't exist, and it changes with every new partner. On campaign days the portal reads these offers about ten times as often as usual. The exam calls this: recommend a solution for storing semi-structured data. Semi-structured means: The data has a structure (fields, nesting), but not the same one for all entries, usually as JSON.
Prior knowledge. The difference between relational and document and Cosmos DB for NoSQL in five terms (account, database, container, item, partition key) is taught by K3 in lesson 3.6.4; K3 shows Azure SQL in lesson 3.6.1. That is not repeated here. What is new are the choice of API, consistency, throughput mode and partition key by requirement, together with the limits that flip them. Backup and high availability of this data follow in lesson 3.4.
The requirement
All numbers are assumptions of the task.
| Requirement | Source | Measure (assumption) |
|---|---|---|
| Offers from about 120 partners, each with its own fields | Product | no fixed schema; new fields without a rebuild |
| Reading dominates | Operations | 800 reads per second on average, 8,000 on campaign days |
| Own changes visible immediately | Partner management | staff of a partner see their change on the next read |
| Data stays in the EU | Data protection | germanywestcentral plus a second EU region for reading |
| Survive the failure of the main region | Management | loss of at most 15 minutes of writes |
| No keys in the code | Security | sign-in with managed identity |
| One large partner (airline) | Product | more than 60 GB of offer data alone |