Section 5: The Band That Fires - Data Modeling
Executive Summary: We rank access patterns by volume, key the watch store by hash(asin) so a price change touches one shard, and introduce the index that carries the design: the crossing band on (marketplace, asin, state, target_minor), which selects only the watches a drop can fire. Then we place each dataset in its store and weigh Postgres against DynamoDB.
Interviewer: "Show me your tables."
You: "First, what we read and how often. The schema falls out of the access patterns."
Access Patterns First, Ranked by Volume
| # | Access pattern | Rate (from Section 3) | Shape |
|---|---|---|---|
| 1 | Due products by next_check_at |
~2,700 checks/s normal, ~4,675/s Prime Day | Ordered range per shard |
| 2 | Product by ASIN (lookup + change detector) | ~3,500/s Prime Day lookups, plus every fetch result | Point read |
| 3 | Armed watches for an ASIN in a price band | 135 change events/s normal, 500/s Prime Day | Range scan, up to 500K rows |
| 4 | Watches by user ("my watches") | Low, user-driven | Range by user |
| 5 | Subscriptions by user | Once per intent, ~8.3K/s at the 10K pushes/s burst | Small range by user |
| 6 | Delivery ledger by notification id | Once per push attempt | Conditional point write |
Patterns 1 to 3 key on the ASIN, 4 and 5 on the user, 6 on neither. One model can't serve three keys well.
Sign in to continue reading
The rest of this lesson is available with a free account. Signing in with Google or Microsoft is free.
Sign in to read the full lesson