Design and develop database solutions
Model around access patterns, not entities
The NoSQL API scales per logical partition, so the partition key is the single most consequential decision. Choose a property present on every item, with high cardinality, that appears in your most frequent filter. Embed related data (an order with its line items) when the children are always read and written with the parent and stay bounded; reference them when they grow without limit or are shared across parents. Keep the hard limits in mind: 2 MB per item, 20 GB per logical partition, 100 operations and 2 MB total per transactional batch, and 2,048 bytes per partition key value. Hierarchical partition keys (up to three levels) spread a formerly hot prefix across many logical partitions.
Indexing, consistency, and concurrency
Five consistency levels exist - strong, bounded staleness, session, consistent prefix, and eventual - with session as the default and the usual answer for per-user read-your-writes. Strong consistency is not available when an account has more than one write region. The default indexing policy indexes every path (/*) with range indexes; excluding unused paths reduces write RU, and a composite index is required for ORDER BY on multiple properties. Optimistic concurrency uses the item ETag with If-Match; a mismatch returns 412.
Worked rule of thumb
If every query filters on customerId, batch-write operations share a partition key, and no single customer can exceed 20 GB, make /customerId the partition key and embed line items. The recurring trap: cross-partition queries and transactional batches fail loudly or cost heavily, and partition keys are immutable - changing one requires delete and re-insert. When a question reports high RU on a point read, check whether the query supplies both id and the partition key; a point read is 1 RU per 1 KB only when both are known.