Write the access patterns before you draw a table
List entities and relationships, then every read and write with its peak rate. Those rates pick the keys, the indexes and what to copy.
Use email as the key?
Bad: Natural keys feel stable
People change email; numbers get recycled.
Good: Surrogate key, plus UNIQUE
A made-up ID as primary key, UNIQUE on the natural one.
Random UUIDs scatter inserts; UUIDv7 appends
UUIDv4 dirties a random leaf page per insert, so the whole index must stay in memory. UUIDv7 starts with a timestamp, so inserts land at the right edge.
In MongoDB: embed or reference?
- Embed: read together, owned and bounded
- Reference: unbounded, shared or read alone
- A document must stay under 16 MiB
- So orders get their own collection
DynamoDB: the keys come from the questions
A user’s profile and orders share one partition key, sorted by SK. “My orders” is one Query over a contiguous range; order detail is one GetItem.
1,000
write units a second per DynamoDB partition
A mega-seller taking 2,000 orders a second overflows SELLER#7#OPEN. Add suffixes #0 to #9 and query all ten in parallel.
The product page shows a star rating. 17,000 reads a second, 6 reviews a second.
Precompute it
Keep rating_sum and rating_count on the product, updated in the review’s transaction. Sum and count, not the average.
Remember
Let the access patterns pick the keys. Snapshot what was true; copy anything else only with a sync path.