2B. Data Modeling, Indexing, and Partitioning

Choose the data model from business invariants and access patterns. First make the simple store work well: model the data, use constraints, create the indexes required by real queries, and measure. Partition or shard only when scale or isolation requirements justify the permanent complexity.

Practical progression

Figure 2. Optimize and measure before accepting sharding complexity.

• Core entities and relationships are identified before choosing a physical schema.

• Read/write/query patterns are listed before choosing a data-store model.

• Transaction and consistency needs are known.

• Indexes support important query predicates, joins, ordering, or uniqueness.

• Index write/storage overhead is accepted and monitored.

• Large binary objects use object/blob storage when that is the better fit.

• Sharding is justified by a real or forecasted storage/write/concurrency limit.

• Shard/partition key distributes load and aligns with dominant queries.

• Hot partitions, cross-shard queries, rebalancing, backup, and recovery are considered.

• Current service limits and quotas are checked instead of relying on memorized numbers.

Evidence: S6, S7, S36, S37, S38, S43, S44