AWS DynamoDB — Interview & Certification Prep

NoSQL fundamentals: tables, items & access patterns

DynamoDB is a fully-managed NoSQL key-value/document store with single-digit-millisecond latency at any scale. Data is organized into tables of items (rows), each a set of attributes. Unlike a relational database you do NOT design a normalized schema and then query it freely — you design around your known ACCESS PATTERNS first, then choose keys and indexes that serve them efficiently. It scales horizontally with no capacity planning of servers.

• Managed NoSQL, single-digit-ms latency, horizontal scale
• Tables of items (attributes); no joins, no ad-hoc query planner
• Design around access patterns FIRST, then keys/indexes

Exam tip: DynamoDB gives predictable low latency at scale ONLY when you design for access patterns. If a question needs flexible ad-hoc queries or joins, that's RDS, not DynamoDB.

Source: AWS docs — DynamoDB Developer Guide

Partition key, sort key & composite keys

Every item is located by its primary key. A simple key is just a partition key (hash key) — items are distributed across partitions by a hash of this value, so it must have high cardinality to spread load. A composite key adds a sort key: items with the same partition key are stored together, sorted, enabling efficient range queries (e.g. all orders for a customer, newest first). Good key design encodes your main access patterns directly into the keys.

• Partition (hash) key spreads items across partitions — use high cardinality
• Sort key groups + orders items within a partition (range queries)
• Encode access patterns into the partition + sort key

Exam tip: partition key = WHICH partition; sort key = ORDER/RANGE within it. "Get all X for a Y, sorted by time" ⇒ partition key Y, sort key time.

Source: AWS docs — DynamoDB Developer Guide

Query vs Scan

Query fetches items by an exact partition key (optionally narrowed by a sort-key condition) and reads only the matching items — efficient and the normal way to read. Scan reads the ENTIRE table and filters afterward — expensive and slow at scale, acceptable only for small tables, exports or admin tasks. If you find yourself needing Scan for a routine access pattern, that's a signal the key/index design doesn't fit the pattern.

• Query = by partition key (+ sort condition), reads only matches — efficient
• Scan = reads the whole table then filters — expensive, avoid at scale
• Needing Scan routinely means the data model is wrong for that pattern

Exam tip: Prefer Query; avoid Scan on large tables. A filter expression on a Scan still READS (and charges for) the whole table before filtering.

Source: AWS docs — DynamoDB Developer Guide

Eventual vs strong consistency

By default reads are eventually consistent — a read right after a write might not see the latest value (usually within a second) — and they cost half as much. A strongly-consistent read always returns the latest committed data but costs more read capacity and isn't available on GSIs. Choose strong consistency only where staleness is unacceptable (e.g. read-after-write on a balance); use the cheaper eventual reads elsewhere.

• Eventual (default): possibly stale for ~a second, cheaper
• Strong: always latest, costs more, NOT available on GSIs
• Use strong only where read-after-write correctness is required

Exam tip: Strong consistency is opt-in, costs more RCUs, and is unavailable on GSIs. Eventual is the cheaper default.

Source: AWS docs — DynamoDB Developer Guide

Comparison: DynamoDB vs RDS

DynamoDB vs RDS is a foundational data-store decision. DynamoDB: NoSQL, key-value/document, single-digit-ms at massive scale, access-pattern-first, no joins/ad-hoc queries, horizontal scaling with no server management. RDS: relational SQL, joins, multi-row transactions, flexible ad-hoc queries, vertical + read-replica scaling with a capacity ceiling. Choose DynamoDB for known, high-scale key-based access patterns; choose RDS/Aurora when you need relational integrity, joins, or unpredictable queries.

• DynamoDB: NoSQL, access-pattern-first, huge scale, no joins/ad-hoc queries
• RDS: relational, joins/transactions/ad-hoc queries, capacity ceiling
• Pick by access pattern: known key-based/high-scale ⇒ DynamoDB; relational/flexible ⇒ RDS

Source: AWS docs — DynamoDB Developer Guide

Secondary indexes: GSI vs LSI

Secondary indexes add alternative query patterns. A Global Secondary Index (GSI) has its OWN partition/sort key, its own capacity, and is updated asynchronously (eventually consistent) — you can add many, any time, to query by a different attribute. A Local Secondary Index (LSI) shares the table's partition key but adds an alternative sort key, must be created WITH the table, and supports strongly-consistent reads. GSIs are the flexible, common choice; LSIs are for extra sort orders on the same partition key.

• GSI: own keys + capacity, eventually consistent, add anytime (flexible)
• LSI: same partition key, alternate sort key, created with the table, strong reads possible
• Use GSIs to serve additional access patterns

Exam tip: GSI = different partition key, eventually consistent, add anytime. LSI = same partition key + new sort key, created with the table.

Source: AWS docs — DynamoDB Developer Guide

Capacity modes, throttling & hot partitions

DynamoDB has two capacity modes: on-demand (pay per request, scales automatically — great for spiky/unknown traffic) and provisioned (you set read/write capacity, optionally with auto scaling — cheaper for steady, predictable load). Requests that exceed available capacity are THROTTLED. A common cause is a hot partition: a low-cardinality partition key concentrates traffic on one partition even if the table's total capacity is high. Fix it with a higher-cardinality or composite key so load spreads.

• On-demand (auto, per-request) vs provisioned (set capacity, cheaper when steady)
• Exceeding capacity → throttling
• Hot partition (low-cardinality key) throttles despite high total capacity — spread the key

Exam tip: Unpredictable/spiky traffic → on-demand. Steady & predictable → provisioned (with auto scaling). Throttling on a "big enough" table usually means a hot partition key.

Source: AWS docs — DynamoDB Developer Guide

Transactions, Streams, TTL & Global Tables

DynamoDB adds several capabilities beyond simple reads/writes: transactions for all-or-nothing multi-item writes; DynamoDB Streams, an ordered change log you can process with Lambda (event-driven pipelines, replication, aggregation); TTL to auto-expire items by a timestamp attribute (cheap cleanup of sessions/temp data); and Global Tables for active-active multi-Region replication (low-latency global reads/writes and Region-level DR). These turn DynamoDB from a store into an event source and a global database.

• Transactions: all-or-nothing multi-item writes
• Streams → Lambda: event-driven processing/replication/aggregation
• TTL auto-expires items; Global Tables = active-active multi-Region

Exam tip: Auto-expire old items = TTL. Multi-Region active-active = Global Tables. React to changes = Streams + Lambda.

Source: AWS docs — DynamoDB Developer Guide