What Does Cosmos DB Design Mean?
Also known as: Cosmos DB Design, Azure Cosmos DB, partition key, AZ-305, consistency level
On This Page
Quick Definition
Cosmos DB Design means planning how you store and organize your data in Microsoft's cloud database. It involves picking the right data model, choosing a partition key, and setting consistency levels. Good design makes your app fast and keeps costs down. Bad design can make your database slow and expensive.
Must Know for Exams
Cosmos DB Design is a heavily tested topic in the Microsoft Azure Solutions Architect (AZ-305) exam. This exam focuses on designing infrastructure solutions, and Cosmos DB appears in the section on data storage design. The exam objectives include recommending a data storage solution, designing for data partitioning, designing for data replication, and designing for performance and cost. Candidates must be able to choose between Cosmos DB and other Azure data stores like Azure SQL Database, Azure Table Storage, or Azure Cache for Redis based on requirements.
Specific exam areas where Cosmos DB Design appears include selecting the appropriate API for a given workload. For example, if an application requires a graph database, the Gremlin API is correct. If the application uses MongoDB drivers, the MongoDB API is correct. The exam also tests understanding of consistency levels. A question might describe an application that needs low latency reads with the ability to tolerate a few seconds of staleness, the correct answer is Bounded Staleness consistency. Another question might describe a global e-commerce site that needs strong consistency for order processing but can tolerate weaker consistency for product reviews, the answer involves multiple containers with different consistency settings.
Partition key selection is a frequent exam topic. Questions present a scenario with a dataset and ask which property is the best partition key. The correct answer is the property with high cardinality, even distribution of writes, and frequent use in query filters. The exam also tests the concept of synthetic partition keys. If no natural property has high cardinality, you can create a new property by combining two or more existing properties.
Request Units are tested through scenario questions that ask how to handle high throughput. For example, if an application is experiencing throttling, the solution might be to increase provisioned RU/s, implement retry logic, or redesign the partition key to avoid hot partitions. The exam expects candidates to understand that you cannot change the partition key of an existing container, you must create a new one and migrate data.
Indexing policy is tested less frequently but appears in advanced scenarios. A question might ask how to reduce write RU consumption for a container that only uses equality-based queries. The correct answer is to set the indexing policy to exclude all properties except those used in query filters.
The AZ-305 exam also covers multi-region replication and failover. Candidates should know the difference between automatic and manual failover, and when to use multi-region writes. A scenario might describe an application that requires 99.999 percent uptime, the solution is to enable multi-region writes across at least two regions.
Simple Meaning
Imagine you are organizing a huge library with millions of books. Cosmos DB Design is like deciding how to arrange those books so that visitors can find what they need quickly and easily. If you just stack books randomly, finding a single book becomes a nightmare.
But if you sort them by genre, then by author, and then by title, you create a system that works for everyone. In Cosmos DB, you are the librarian. You decide how to divide your data into containers and how to choose a partition key, which is like deciding which shelf each book goes on.
The partition key is a property in your data that Cosmos DB uses to spread your data across multiple servers, called partitions. For example, if you have data about customers, you might use their country as the partition key. Customers from the same country would be stored together on the same server.
This makes queries for customers in one country very fast because the database only needs to look at one server. But if you choose a bad partition key, like a customer ID that is completely random, you might create too many small groups or one huge group that slows everything down. Think of it like a post office sorting mail.
The postal code is the partition key. If everyone with the same postal code is in one pile, the mail carrier can deliver quickly. But if you mix all postal codes together, the carrier wastes time sorting through everything.
Cosmos DB Design also decides how consistent your data needs to be. Strong consistency means every copy of your data is identical at all times, like making sure every office across the country has the exact same employee directory. Weaker consistency means some copies might be a few seconds behind, which is fine for things like social media likes but not for bank balances.
Finally, Cosmos DB Design involves choosing the right index for your queries. An index is like a book index that tells you exactly which page a topic is on. Without an index, Cosmos DB has to scan every piece of data to answer a query, which is slow and expensive.
By designing your indexes to match the queries your app runs most often, you make the database lightning fast. In short, Cosmos DB Design is all about making smart choices upfront so your database works smoothly as it grows.
Full Technical Definition
Azure Cosmos DB is a fully managed, globally distributed NoSQL database service. Cosmos DB Design refers to the architectural decisions made when modeling data and configuring the database to meet specific performance, latency, availability, and cost requirements. The core components of Cosmos DB Design include data modeling, partition key selection, indexing policy, consistency level, and request unit (RU) provisioning.
Data modeling in Cosmos DB differs from relational databases. Instead of normalizing data into multiple tables with foreign keys, Cosmos DB encourages denormalization. Data is stored as JSON documents within containers. A container is the unit of scalability. Each container has a partition key, which is a property in every document that determines how data is distributed across physical partitions. The partition key is critical because it defines the logical grouping of data. When a query includes the partition key in its filter, Cosmos DB routes the query to the exact partition containing the data, resulting in efficient point reads. Queries without the partition key perform fan-out queries, hitting all partitions, which consumes more RUs and increases latency.
Request Units (RUs) are the currency of throughput in Cosmos DB. Every operation consumes RUs based on item size, indexing, and consistency. Design decisions directly impact RU consumption. For example, using a highly selective index can reduce RU cost for read operations. Conversely, writing large documents with many indexed properties increases RU cost for writes. Provisioned throughput can be set at the container or database level. Autoscale and manual throughput modes allow designers to balance cost and performance.
Consistency levels range from Strong (highest consistency, lowest availability) to Eventual (lowest consistency, highest availability). Between these are Bounded Staleness, Session, and Consistent Prefix. Azure Cosmos DB guarantees low latency (single-digit milliseconds) for reads and writes at any consistency level. However, Strong consistency requires a quorum of replicas, which can impact write latency in geo-distributed setups.
Indexing policy is another design consideration. By default, all properties in a JSON document are indexed. Designers can customize the indexing policy to include or exclude specific paths. Composite indexes can be created for multi-property queries that use ORDER BY with multiple fields. Geospatial indexing is available for location-based data.
Change feed is a powerful feature that enables event-driven architectures. When data changes, the change feed emits the modified documents in order. This is used for real-time analytics, data synchronization, or triggering Azure Functions.
Multi-model support allows storing documents, graphs, key-value pairs, and column-family data. The API choice (SQL, MongoDB, Cassandra, Gremlin, or Table) affects how queries are written. The SQL API is the native API and supports SQL-like querying with JavaScript user-defined functions and stored procedures.
Global distribution is achieved by adding Azure regions to a Cosmos DB account. Multi-region writes and automatic failover require careful design to avoid conflicts. Conflict resolution policies can be last-writer-wins or custom via stored procedures.
In real IT environments, Cosmos DB Design is implemented during the solution architecture phase, often using the Azure Well-Architected Framework. Performance benchmarking with tools like Azure Load Testing validates RU assumptions. Monitoring is done through Azure Monitor and Cosmos DB metrics, tracking metrics like normalised RU consumption, request latency, and throttled requests. Design decisions are documented in the Azure Architecture Center, and changes to partition key or indexing policy require data migration.
Real-Life Example
Think of a large hospital with a patient record system. Each patient has a medical file, and the hospital has many departments: cardiology, orthopedics, emergency, and pediatrics. The partition key in this analogy is the department name.
When a doctor in cardiology needs a patient's records, they go directly to the cardiology filing cabinet. They do not need to search through the entire hospital. This makes finding information fast and easy.
Now imagine the hospital uses the patient's last name as the partition key. One filing cabinet might hold all patients with last names starting with A. If there are 10,000 patients named Anderson, that cabinet becomes overcrowded and slow.
Meanwhile, the cabinet for Z is nearly empty. This is called a hot partition, where one partition handles too much traffic while others are idle. In Cosmos DB, a hot partition leads to throttling, meaning requests are delayed or rejected until the system catches up.
The hospital's solution is to choose a partition key that evenly distributes patient records across all cabinets. They could use the patient ID, which is unique and random, ensuring every cabinet gets roughly the same number of files. But then a doctor needing a specific patient would need to know the patient ID to find the right cabinet.
If they only know the patient's name, they must ask the front desk to look up the ID first. This is the trade-off: using a high-cardinality partition key like patient ID ensures even load distribution but requires queries to include that key for efficiency. The hospital also must decide how consistent their records need to be.
If a doctor in cardiology updates a patient's medication, should the pediatrics department see that change immediately? In an emergency, yes. But for routine follow-ups, a few seconds delay is acceptable.
The hospital chooses a session consistency level, meaning changes are immediately visible to the same doctor but may take a moment to reach other departments. This balances speed with accuracy.
Why This Term Matters
Cosmos DB Design matters because it directly determines whether your cloud application succeeds or fails in production. A poorly designed Cosmos DB can lead to excessive costs, slow response times, and even application downtime. In real IT work, architects and developers make design decisions that affect thousands or millions of users. For example, an e-commerce platform using Cosmos DB for its product catalog must design the partition key so that popular products do not create a hot partition. If all customers searching for a trending item hit the same partition, that partition becomes overloaded, and the app slows for everyone. This is not just a performance issue, it is a lost revenue issue.
Cost management is another critical factor. Cosmos DB charges for provisioned throughput (RUs) and storage. Every query and write consumes RUs. A design that requires scanning every partition for common queries wastes RUs and increases the monthly bill. By choosing the right indexing policy and partition key, you can reduce RU consumption by 50 percent or more. In enterprise environments, where databases can cost tens of thousands of dollars per month, these savings are significant.
Operational complexity also depends on design. If you need to change the partition key later, you must migrate all data to a new container with downtime. Getting it right the first time is cheaper and safer. Similarly, selecting the wrong consistency level can cause compliance issues. Financial applications often require Strong consistency to meet audit requirements, while social media apps can use Eventual consistency for better performance.
Disaster recovery and high availability are built into Cosmos DB, but only if you design for multi-region distribution. Architects must decide which regions to replicate to and whether to enable multi-region writes. This affects both cost and complexity. A bad design can result in data loss during a regional outage if failover settings are not properly configured.
Finally, Cosmos DB Design impacts developer productivity. A well-designed database makes queries simple and fast. A poorly designed one forces developers to write complex workarounds, add caching layers, or even switch to a different database entirely. For IT professionals, mastering Cosmos DB Design is essential for building scalable, cost-effective, and maintainable cloud solutions.
How It Appears in Exam Questions
Cosmos DB Design appears in several question formats on the AZ-305 exam. The most common type is the scenario-based multiple-choice question. For example, the question might describe a company that operates a global retail application with millions of users. The application stores user profiles and shopping cart data. The requirement is low-latency reads for user profiles and strong consistency for shopping cart checkout. The question asks which data storage design to recommend. The correct answer involves using Cosmos DB with two containers, one for user profiles with Session consistency and one for shopping carts with Strong consistency. The distractors might include using a single container with Strong consistency for all data, which would increase cost and latency unnecessarily.
Another question pattern involves choosing a partition key. The scenario provides a dataset of IoT sensor readings with properties like device ID, timestamp, temperature, and location. The requirement is to efficiently query all readings for a specific device within a time range. The best partition key is device ID because queries always filter by device ID, and each device generates a relatively even amount of data. A distractor might be timestamp, which would cause uneven distribution because not all time periods have equal data, and queries would often span multiple partitions.
Configuration questions test understanding of RU provisioning. For instance, a question might show a container that is throttling writes during peak hours. The options include increasing RU/s, enabling autoscale, changing the partition key, or adding a secondary index. The correct answer depends on the scenario. If the partition key is causing a hot partition, increasing RU/s alone might not fix the imbalance. The question expects you to identify the root cause first.
Troubleshooting questions present a scenario where an application experiences high latency for read queries. The question asks for the most likely cause. The answer could be that queries are not using the partition key, causing fan-out across all partitions. Other causes include missing indexes or a suboptimal consistency level.
Architecture questions ask you to design a solution from scratch. For example, design a real-time leaderboard for a gaming application that runs globally. You must select Cosmos DB API, partition key, consistency level, indexing policy, and replication strategy. The correct design uses the SQL API, partition key on game ID, Bounded Staleness consistency to balance speed and accuracy, a default indexing policy, and multi-region writes for the leaderboard updates. The question might present your design as a diagram or description, and you need to identify the flaw.
Some questions use drag-and-drop ordering, where you must put the steps of migrating a Cosmos DB database into the correct sequence: analyze current schema, choose new partition key, create new container, migrate data using Azure Data Factory, update application connection strings, and test performance.
Practise Cosmos DB Design Questions
Test your understanding with exam-style practice questions.
Example Scenario
A company called FreshGrocery runs an online grocery delivery service. They store all product information in Azure Cosmos DB, including item name, category, price, stock level, and supplier. The application frequently shows customers all products in a specific category, like dairy or vegetables.
The development team initially chooses the category property as the partition key. During normal times, this works fine. But during the holiday season, the dairy category gets ten times more traffic because everyone buys milk and cheese.
The dairy partition becomes a hot partition, causing slow response times and throttling for users browsing dairy products. Meanwhile, categories like spices see very little traffic and are underutilized. The team realizes their design mistake.
They change the partition key to a combination of the item ID, which is a unique random value. Now all partitions receive roughly equal traffic. However, queries for all items in a category now require scanning all partitions, which costs more RUs.
To fix this, they create a secondary index on the category property. This allows queries to efficiently find all items in a dairy category without scanning every partition. They also add a composite index for queries that filter by category and then sort by price.
After these design changes, the application handles holiday traffic smoothly, and the monthly Cosmos DB bill decreases because queries no longer cause fan-out scans unnecessarily. This scenario shows how partition key choice, indexing policy, and composite indexes work together in Cosmos DB Design.
Common Mistakes
Choosing a partition key with low cardinality, such as a boolean value or a small set of categories, which leads to hot partitions.
Low cardinality means only a few partition key values exist, so data does not spread evenly across partitions. This causes one partition to handle most of the traffic while others remain idle, leading to throttling and poor performance.
Select a partition key that has many unique values, ideally hundreds of thousands or more. Examples include user ID, device ID, or order ID. Avoid keys with fewer than 1000 unique values.
Using Strong consistency for all containers regardless of the application's actual needs, which increases write latency and RU cost.
Strong consistency requires all replicas to commit before acknowledging a write. This is unnecessary and costly for many applications, like logging or analytics, that can tolerate a few seconds of staleness.
Assess each workload's consistency requirements separately. Use Session consistency by default, which provides strong consistency for the same user session. Use Strong consistency only when data integrity is critical, such as financial transactions.
Designing the data model with too many small documents and high cross-document references, similar to a normalized relational database.
Cosmos DB is designed for denormalized data. Frequent joins between documents require extra queries or client-side processing, increasing latency and RU consumption.
Embed related data as nested arrays or subdocuments within a single JSON document. For example, store order items inside the order document instead of in a separate items container.
Not using composite indexes for queries that filter on multiple properties and sort by one of them, resulting in full index scans.
Without a composite index, Cosmos DB cannot efficiently satisfy ORDER BY with multiple filter conditions. The query engine may scan many documents or return an error if the combination is not indexed.
Create a composite index for each multi-property query pattern. For example, if you query by category and then sort by price, add a composite index on (category ASC, price ASC).
Setting the indexing policy to include all paths by default for write-heavy workloads, which increases RU consumption and slows writes.
Every write operation must update the index for each included path. The more paths indexed, the higher the write RU cost. Indexing paths that are never queried wastes resources.
Analyze your query patterns and set the indexing policy to include only the paths used in filters and order-by clauses. Exclude irrelevant data like large binary fields or internal metadata.
Exam Trap — Don't Get Fooled
A question asks you to choose a partition key for a container that stores time-series IoT data. The options include 'timestamp', 'device_id', 'region', and 'reading_type'. Many learners choose 'timestamp' because it seems logical to group data by time.
Remember that a good partition key must evenly distribute data across partitions. A timestamp as partition key creates a new partition for each time unit, but writes for the current time unit all go to the same partition, creating a hot partition. The correct choice is usually 'device_id' because each device generates data continuously and evenly, and queries typically filter by device_id first.
Always prioritize even write distribution and query filter patterns over natural grouping.
Commonly Confused With
Azure SQL Database uses a relational model with normalized tables, schemas, joins, and strict ACID transactions. Cosmos DB uses a NoSQL document model with denormalized data, flexible schema, and tunable consistency. Design for Azure SQL focuses on normalization and indexing, while Cosmos DB design focuses on partition key selection and embedding data.
In Azure SQL, you store a customer in one table and orders in a related table with a foreign key. In Cosmos DB, you store the customer as a document that contains an array of orders embedded directly inside it.
Azure Table Storage is a key-value store with a flat namespace, limited query capabilities, and no indexing flexibility. Cosmos DB offers rich indexing, multi-model APIs, global distribution, and multiple consistency levels. Table Storage design is simpler but less powerful, and can be migrated to Cosmos DB using the Table API.
In Azure Table Storage, you query by partition key and row key only. In Cosmos DB, you can query any property with SQL-like syntax, use composite indexes, and perform geospatial queries.
Relational schema design focuses on normalization to eliminate data redundancy and ensure referential integrity through constraints like primary and foreign keys. Cosmos DB design favors denormalization to embed related data, avoiding joins and reducing query complexity. Relational design prioritizes write consistency, while Cosmos DB design prioritizes read performance and scalability.
A shopping cart in a relational database might have separate tables for cart, cart_item, and product. In Cosmos DB, the same cart is a single document containing an array of product objects with all relevant details.
While both are NoSQL document databases, Cosmos DB is cloud-native with automatic indexing, multi-region writes, and multiple APIs including a MongoDB-compatible one. MongoDB is traditionally deployed on-premises or in a cloud VM with manual sharding and replication. Cosmos DB design includes consistency levels like Bounded Staleness that MongoDB does not have natively.
In MongoDB, you create an index explicitly for queries. In Cosmos DB, indexes are created automatically for all properties unless you change the policy, which simplifies initial design but requires optimization for large workloads.
Step-by-Step Breakdown
Analyze Application Requirements
Begin by understanding the workload: read-heavy or write-heavy, latency requirements, consistency needs, data size, and query patterns. Document which queries will run most frequently, which properties are used in filters and sorts, and whether the application needs global distribution. This step sets all design decisions.
Choose the Cosmos DB API
Select the API that matches your application's existing drivers or preferred query language. The SQL API is recommended for new projects because it offers the richest query capabilities and native support. Use MongoDB API if migrating from MongoDB, Gremlin API for graph data, Cassandra API for Cassandra workloads, and Table API for Azure Table Storage migration. The API choice affects how you write queries and what features are available.
Select the Partition Key
Identify a property in your data with high cardinality (many unique values), even write distribution, and frequent use in query filters. Avoid properties that change value or are based on monotonically increasing values like timestamps. For workloads without a natural partition key, create a synthetic key by concatenating two or more properties. Test the candidate key with sample data to confirm even distribution.
Define the Data Model
Model your data as JSON documents. Embed related data that is read together frequently to avoid cross-document lookups. For example, embed order line items inside the order document, and embed customer address inside the customer document. Avoid deep nesting beyond a few levels. For large data like images, store a reference to Azure Blob Storage instead of embedding binary data.
Configure the Indexing Policy
Start with the default policy that indexes all properties. Then customize it to exclude properties that are never queried, reducing write RU cost and storage. Add composite indexes for queries using ORDER BY with multiple properties. For write-heavy containers, consider a policy that only indexes the partition key and a few filter properties. Test the policy with representative queries.
Set the Consistency Level
Choose the consistency level based on the workload's tolerance for staleness. Use Session consistency for most multi-user applications as it balances performance and correctness. Use Strong consistency for financial or compliance-critical data where immediate global consistency is required. Use Eventual consistency for high-throughput, non-critical data like clickstream logs. Configure Bounded Staleness for an adjustable trade-off between consistency and latency.
Provision Throughput and Configure Global Distribution
Estimate required RU/s based on peak workload. Use autoscale for variable workloads to avoid over-provisioning. For multi-region deployments, enable multi-region writes if low write latency is critical. Configure automatic failover for high availability. Monitor RU consumption and adjust provisioning over time.
Practical Mini-Lesson
To design a Cosmos DB solution in practice, start by gathering detailed requirements. Speak with application developers to understand the exact queries the app will run. Ask questions like: Which properties will appear in WHERE clauses? Which properties will be used for sorting? How often are reads versus writes? What is the maximum acceptable latency for reads and writes? These answers drive every design decision.
Next, sketch your data model on paper. For each entity, list its properties and relationships. Decide which entities should be embedded and which should be separate containers. A good rule of thumb is that if an entity is always accessed together with its parent, embed it. If it is accessed independently or is very large, put it in its own container. For example, in an order management system, embed order items but store customer history in a separate container because it is queried separately.
Now choose your partition key. This is the most impactful decision. Use the property that appears in the majority of your queries and has at least 10,000 unique values for a production workload. If you must use a low-cardinality property, consider distributing writes evenly by adding a hash suffix. For example, instead of using region as partition key, use region with a random number from 1 to 10 to create more partitions.
after selecting the partition key, estimate your RU requirements. Use the Cosmos DB capacity calculator. For a read-heavy workload, calculate the average document size and the number of reads per second. Multiply by the RU cost of a point read (1 RU for 1 KB document) to get a baseline. Add overhead for queries and indexing. For writes, calculate RU cost as 5 RUs per 1 KB document, plus indexing overhead. Adjust for the chosen consistency level.
Implement your design in a development environment. Use the Cosmos DB emulator for local testing. Write the exact queries your application will use and measure RU consumption with the Azure Portal or SDK metrics. If a query consumes more RUs than expected, check if the partition key is included in the filter. If not, consider denormalizing data to include the partition key. Also verify that indexes are being used by checking the query execution stats.
Monitor production with Azure Monitor. Set alerts for normalised RU consumption above 80 percent, which indicates you are approaching throttling. If throttling occurs, first check for hot partitions by examining partition-level metrics. If one partition uses significantly more RU/s than others, redesign your partition key. If throttling is uniform across partitions, increase provisioned throughput.
Finally, plan for schema evolution. Cosmos DB is schemaless, but your application logic expects certain properties. Use change feed to trigger schema migrations without downtime. For example, when adding a new property, update new documents directly and use a change feed function to backfill existing documents with a default value.
A common mistake in practice is over-provisioning RUs to avoid design complexity. This wastes money. A well-designed Cosmos DB can serve millions of requests per second with only a few thousand RUs because queries are efficient. Invest time in design upfront to save costs and ensure reliability in production.
Memory Tip
Remember the four pillars of Cosmos DB Design with the acronym PATH: Partition key choice, API selection, Throughput (RU) estimation, and High availability (consistency and geo-replication). Always check if your queries include the partition key.
Covered in These Exams
Current Exam Context
Current exam versions that test this topic — use these objectives when studying.
AZ-305AZ-305 →Related Glossary Terms
Frequently Asked Questions
What is the most important decision when designing Cosmos DB?
Choosing the right partition key is the most critical decision. It affects performance, cost, and scalability. A bad partition key can cause hot partitions and throttling, which slows down your entire application.
Can I change the partition key after creating a container?
No, you cannot change the partition key on an existing container. You must create a new container with the correct partition key and migrate your data using Azure Data Factory or a custom migration tool.
What consistency level should I use by default?
Session consistency is the recommended default for most applications. It provides strong consistency for the same user session while offering low latency and high throughput for global users.
How do I know if my partition key is causing a hot partition?
Monitor the Normalized RU Consumption metric in Azure Portal. If one partition shows significantly higher consumption than others, you have a hot partition. Check the Partition Key Range Distribution chart to confirm.
Does Cosmos DB support joins?
Cosmos DB SQL API supports limited JOIN operations within the same document or between documents in the same container using subqueries. However, cross-container joins are not supported. The recommended approach is to embed related data to avoid the need for joins.
What is a synthetic partition key and when should I use it?
A synthetic partition key is a new property you create by concatenating two or more existing properties to increase cardinality. Use it when no single property has enough unique values for even distribution, such as combining state and customer ID.
How does indexing policy affect write performance?
Every indexed property adds overhead to write operations. If you have many indexed paths, writes consume more RUs and take longer. For write-heavy workloads, minimize the number of indexed paths to reduce cost and improve performance.
What is the difference between automatic and manual failover in Cosmos DB?
Automatic failover is driven by Azure and triggers when a region becomes unavailable. Manual failover allows you to designate a different region as the write region at any time. Automatic failover is simpler, but manual gives you more control during planned maintenance.
Summary
Cosmos DB Design is the practice of making informed decisions about data model, partition key, indexing, consistency, and throughput when using Azure Cosmos DB. These decisions directly impact application performance, operational cost, and scalability. For IT professionals and Azure solution architects, mastering Cosmos DB Design is essential for building cloud-native applications that can handle global traffic with low latency.
The AZ-305 exam tests this knowledge through scenario-based questions that require you to recommend the right partition key, consistency level, indexing policy, and API for a given workload. Common mistakes include choosing a low-cardinality partition key, overusing Strong consistency, and modeling data in a normalized relational style. To avoid these pitfalls, always start by analyzing query patterns, embed related data, use session consistency as a default, and create composite indexes for multi-property queries.
Remember the acronym PATH: Partition key, API, Throughput, and High availability. A well-designed Cosmos DB can serve millions of requests per second efficiently, while a poor design leads to throttling, high costs, and frustrated users. Use the Cosmos DB emulator and Azure Monitor to test and validate your design before going to production.