Document Databases and JSON Storage

az cosmosdb create --name mycosmosdb --resource-group myrg --kind GlobalDocumentDB
az cosmosdb sql database create --account-name mycosmosdb --name mydatabase --resource-group myrg
az cosmosdb sql container create --account-name mycosmosdb --database-name mydatabase --name mycontainer --partition-key-path "/id" --resource-group myrg

To insert a document using the SQL API:

{
  "id": "1",
  "name": "John Doe",
  "address": {
    "street": "123 Main St",
    "city": "Seattle"
  },
  "orders": [
    {"product": "Laptop", "price": 999.99}
  ]
}

Query using SQL-like syntax:

SELECT * FROM c WHERE c.name = "John Doe"

Scenario 1: E-commerce Product Catalog A large online retailer stores product information in Azure Cosmos DB using the document model. Each product document contains fields like name, description, price, category, and a list of variants (size, color, stock). The partition key is the category ID, ensuring that all products in the same category are co-located. Queries like "get all electronics products under $500" can be served efficiently using a range index on price. The catalog is updated frequently as prices change, and the schema evolves (e.g., adding a new field for warranty). The document model allows these changes without downtime. Performance is critical: the system handles 10,000 reads per second with 5ms latency. Misconfiguration: if the partition key is too granular (e.g., product ID), each partition gets very few documents, leading to high RU consumption for cross-partition queries.

Scenario 2: User Profile Store for a Social Media App A social media platform stores user profiles in MongoDB (or Cosmos DB with MongoDB API). Each user document contains basic info (name, email), preferences, friend list (array of user IDs), and recent posts (array of embedded post objects). The partition key is the user ID, so all data for a user is in one partition. Reads are by user ID (point reads), which are fast and cheap. Writing a new post appends to the posts array. However, if a user has thousands of posts, the document size may approach the 16 MB limit, causing performance issues. The solution is to store posts in a separate collection with user ID as a foreign key, using a reference rather than embedding. This trade-off is a common design decision.

Scenario 3: IoT Sensor Data Ingestion A manufacturing company ingests sensor readings from thousands of devices into Cosmos DB. Each reading is a JSON document with device ID, timestamp, temperature, humidity, and other metrics. The partition key is device ID, and the collection is configured with a time-to-live (TTL) of 30 days to automatically expire old data. Queries are typically per device (e.g., all readings from device X in the last hour). The document model handles the varying sensor schemas (some devices send extra fields). Misconfiguration: using a partition key that results in a hot partition (e.g., region ID where one region has 80% of devices) causes throttling. The solution is to use a synthetic partition key like device ID hashed to a number of partitions.