dynamodb-patternslisted

# DynamoDB Patterns DynamoDB is a key-value store dressed up as a database. Get the access patterns right at design time and it scales effortlessly; get them wrong and the only fix is a multi-month migration. These patterns prevent the common production-grade mistakes. ## When to Activate - Designing a new table or GSI - Writing or reviewing any `ddb.send(...)` call - Adding a new query pattern to an existing table - Auditing for cross-tenant leak risk - Migrating between key shapes - Diagnosing throttling / hot-partition incidents ## The Core Rule: Access Patterns Define the Schema In a relational DB, you model the data, then query it. In DynamoDB, you enumerate the QUERIES first, then design keys to make each one a single Query (never a Scan). Skipping this step always ends in a costly redesign. For each entity, write down: 1. **List X by Y** — needs `PK = Y` or a GSI on Y 2. **Get specific X** — needs the full PK + SK 3. **List X sorted by date** — SK should be a date-prefixed string If your access pattern is "list all rows that match attribute Z" — that's a Scan, and Scans are forbidden in production code paths. Either add a GSI on Z or denormalize. ## Tenant Isolation: `organization_id` In Every Key Multi-tenant systems MUST use `organization_id` (or equivalent) as the partition key on every base table. Two reasons: 1. **Hot-partition prevention** — one tenant's traffic can't dominate another's RCU/WCU. 2. **Cross-tenant leak prevention** — a forgotten filter