3.1.3. Amazon DynamoDB: NoSQL at Scale

💡 First Principle: DynamoDB trades query flexibility for speed and scale. Unlike relational databases that can answer almost any query (with enough time), DynamoDB answers a narrow set of queries — key-value lookups and indexed range scans — but answers them in single-digit milliseconds at any scale, from ten requests per second to millions. The key design principle: know your access patterns before designing the table.

DynamoDB's data model revolves around tables, items (rows), and attributes (columns). Every table requires a partition key (determines which physical partition stores the item). An optional sort key enables range queries within a partition. Together, the partition key and sort key form the primary key.

Key design patterns for the exam:

Single-table design. Store multiple entity types in one table using composite keys (e.g., PK=CUSTOMER#123, SK=ORDER#456). This enables efficient queries that join related data in a single request. The exam may describe scenarios where the answer involves clever key design rather than adding tables.

Global Secondary Indexes (GSI). Enable queries on non-key attributes. A GSI has its own partition and sort key, creating an alternate access pattern. GSIs are eventually consistent and consume additional write capacity.

Local Secondary Indexes (LSI). Enable range queries on a different sort key within the same partition. LSIs must be created at table creation time and share the base table's capacity.

Capacity modes. On-demand mode scales automatically and charges per request — best for unpredictable workloads. Provisioned mode lets you reserve capacity at lower per-request cost — best for steady workloads. Auto-scaling adjusts provisioned capacity within bounds you set.

⚠️ Exam Trap: DynamoDB is not suited for complex analytical queries (joins, aggregations across the entire table, ad-hoc filters on non-indexed attributes). If a question describes needing "flexible, ad-hoc queries on a DynamoDB table," the answer typically involves exporting to S3 and querying with Athena — not adding more GSIs.

Reflection Question: An e-commerce application stores orders in DynamoDB with customer_id as the partition key and order_date as the sort key. A new requirement asks for "find all orders for product X across all customers." How do you support this access pattern?