DynamoDB Interview Questions

Summary

DynamoDB is AWS's fully managed, serverless key-value and document database. It delivers consistent single-digit-millisecond latency at almost any scale, with no servers, patching or capacity planning in on-demand mode. It fits workloads with known, key-based access patterns and very high or spiky traffic.

Longer Answer

Good fits: user profiles and sessions, shopping carts, order and event data accessed by ID, IoT and time-series ingestion, gaming state, serverless backends with Lambda, and anything needing predictable latency at large scale.

Poor fits: ad-hoc queries and analytics, many-to-many relational reporting, full-text search, and workloads where access patterns are unknown or change often. Those need SQL, a search engine, or exporting DynamoDB data to S3 for analytics.

The core trade-off: DynamoDB scales by forcing you to design tables around how you read and write data, instead of normalising and querying flexibly.

Key Points

• Managed, serverless key-value/document store.
• Predictable low latency at scale.
• Design for known access patterns.
• Not for ad-hoc queries or analytics.

Summary

A primary key is either a simple partition key (each item has a unique partition key value) or a composite of partition key plus sort key (items share a partition key and are unique by sort key). The partition key is hashed to choose the storage partition; the sort key orders items within that partition.

Longer Answer

With a composite key, all items with the same partition key form an item collection, stored together and sorted by sort key. Query can then fetch the whole collection or a range of it (begins_with, between, <, >), which is how one-to-many relationships are modelled: PK = CUSTOMER#123, SK = ORDER#2026-10-17#987.

Good partition keys have many distinct values that spread requests evenly (user ID, order ID). Bad partition keys concentrate traffic (a status flag, today's date).

Code Example

PK              SK                          attributes
CUSTOMER#123    PROFILE                     name, email
CUSTOMER#123    ORDER#2026-10-15#981        total, status
CUSTOMER#123    ORDER#2026-10-17#987        total, status

Key Points

• Simple PK or composite PK + SK.
• PK is hashed to a partition.
• SK sorts the item collection.
• Query by PK with SK conditions.

Summary

A hot partition receives far more traffic than others, usually because many requests share one partition key value (a celebrity user, today's date as key, a global counter). It throttles even when the table has spare capacity overall. Avoid it with high-cardinality keys and, for unavoidable hot keys, write sharding or caching.

Longer Answer

Techniques:

• Choose keys with many values and even access (user ID, not country).
• Write sharding: append a suffix (EVENT#2026-10-17#7, suffix 0-9 chosen randomly or computed from an attribute) and read all shards in parallel.
• Cache hot reads (DAX or an application cache).
• Aggregate writes (buffer counters in memory or a queue) instead of writing one item per event.

CloudWatch Contributor Insights shows the most accessed keys, which is how you find hot partitions in practice.

Key Points

• Traffic concentrated on one key.
• High-cardinality keys.
• Write sharding with suffixes.
• Cache hot reads; Contributor Insights to find them.

Summary

Start from the access patterns, not the entities: list every query the application needs (with filters, sort order and volume), then design keys and indexes so each pattern is a single GetItem or Query. Denormalise and duplicate data where needed, since there are no joins.

Longer Answer

Relational design normalises first and lets SQL answer any question later. DynamoDB inverts that: flexibility is traded for predictable performance. Steps:

1. Write down entities and relationships, then the access patterns ("get orders for a customer, newest first", "get order by ID", "list open orders by warehouse").
2. Choose primary key formats so related items share a partition key and sort correctly.
3. Add GSIs for patterns the primary key cannot serve.
4. Decide where to duplicate attributes and how to keep copies consistent (transactions or streams).

A new access pattern later may need a new GSI or a backfill, so collect patterns carefully up front.

Key Points

• Access patterns first.
• Each pattern = one GetItem/Query.
• Denormalise; no joins.
• New patterns may need GSIs and backfills.

Summary

A GSI has its own partition key and optional sort key, can be added any time, has its own capacity, and is eventually consistent. An LSI keeps the table's partition key with a different sort key, must be created with the table, shares the table's capacity, supports strongly consistent reads, and limits each item collection to 10 GB.

Longer Answer

GSIs are the default choice: they serve new access patterns on different keys (orders by status, users by email). Writes to the table are propagated asynchronously, and each GSI write consumes write capacity, so many GSIs multiply write cost. If a GSI is under-provisioned it can throttle writes to the base table.

LSIs suit "same partition, different order" patterns that need strong consistency, but the 10 GB item-collection limit and the creation-time-only rule make them rare in new designs. Tables allow up to 20 GSIs by default and 5 LSIs.

Key Points

• GSI: any keys, add any time, eventually consistent.
• LSI: same PK, created with the table, strong reads, 10 GB collections.
• Each index costs writes.
• Prefer GSIs.

Summary

Query reads one item collection (one partition key value), optionally narrowed by a sort key condition, so it reads only the relevant items. Scan reads every item in the table or index and then optionally filters, consuming capacity for everything it reads.

Longer Answer

On a large table a Scan is slow, expensive and can consume capacity needed by live traffic. Legitimate uses: one-off migrations and backfills (use parallel scan with Segment/TotalSegments and rate limiting), small tables, or exports (prefer the managed export to S3, which consumes no table capacity). If a feature needs a Scan in its request path, the data model is missing an index or key design.

Key Points

• Query = one partition, targeted.
• Scan = whole table.
• Scan only for backfills/exports/small tables.
• Export to S3 for analytics.

Summary

A ConditionExpression makes a write succeed only if the condition holds on the current item (attribute_not_exists(PK), version = :expected, balance >= :amount); otherwise it fails with ConditionalCheckFailedException and nothing changes. Optimistic locking stores a version number and updates only when it matches.

Longer Answer

{
  "UpdateExpression": "SET #s = :shipped, version = version + :one",
  "ConditionExpression": "version = :expected AND #s = :paid",
  "ExpressionAttributeNames": {"#s": "status"},
  "ExpressionAttributeValues": {":shipped": "SHIPPED", ":paid": "PAID", ":expected": 7, ":one": 1}
}

Conditional writes are atomic per item and are the main tool for correctness under concurrency: preventing overwrites (attribute_not_exists on create), enforcing invariants, and state-machine transitions. A failed condition costs write capacity. ReturnValuesOnConditionCheckFailure returns the current item so you can explain the conflict.

Key Points

• Write only if the condition holds.
• attribute_not_exists for create-only.
• Version attribute for optimistic locking.
• Atomic per item.

Summary

DynamoDB Streams is an ordered, time-ordered log of item-level changes (new image, old image, or both) retained for 24 hours. Lambda functions or other consumers read it to react to changes: update aggregates, sync search indexes, send notifications, replicate data, or implement an outbox.

Longer Answer

Ordering is guaranteed per item (per partition key, within a shard), not across the table. Delivery to Lambda is at least once, so consumers must be idempotent. Failed batches are retried and block the shard until they succeed or expire, so configure bisecting on error, maximum retry attempts and an on-failure destination (DLQ). Kinesis Data Streams for DynamoDB is an alternative with longer retention and more consumers.

Key Points

• 24-hour change log with images.
• Ordered per item, at-least-once.
• Idempotent consumers; DLQ for poison batches.
• Kinesis option for longer retention.

Deep dive: Node.js Serverless on AWS Lambda: DynamoDB Streams and poison records

Summary

Choose DynamoDB when access patterns are known and key-based, scale or traffic spikes are large, and you want a serverless operational model. Choose a relational database when you need flexible queries, joins, reporting, complex transactions and constraints, or when access patterns are still evolving.

Longer Answer

Questions to ask: Do we know our queries? Do we need ad-hoc reporting? How large and spiky is the load? Does the team know DynamoDB modelling? How important are strict relational constraints?

Many systems use both: relational for the core domain and reporting, DynamoDB for very high-scale, simple patterns (sessions, events, carts). Serverless relational options (Aurora Serverless, Aurora DSQL) have narrowed the operational gap.

Key Points

• Known key-based patterns + scale: DynamoDB.
• Flexible queries and reporting: relational.
• Team skills matter.
• Using both is common.

Summary

List the patterns first, for example: get an order by ID; list a customer's orders newest first; get an order with its line items; list orders by status for the warehouse; look up a customer by email. Then map each to a key or index.

Longer Answer

One reasonable design:

Write the order summary under the customer and the full order under its own key in one transaction, update status with a conditional write (state machine), and use a stream to notify fulfilment. Mention trade-offs: duplicated order summaries, status-bucket sharding, and where reporting will happen (export to S3).

Key Points

• Start with access patterns.
• Map each to a key or GSI.
• Avoid hot status partitions.
• Transactions, conditions and streams for consistency.

Summary

DynamoDB hashes the partition key to place items on partitions (storage units of up to about 10 GB). Each partition supports up to 3,000 read capacity units and 1,000 write capacity units per second. Tables split partitions automatically as data or traffic grows.

Longer Answer

Because limits are per partition, a table with huge total capacity can still throttle if one partition key receives a disproportionate share of traffic. DynamoDB mitigates this with adaptive capacity (shifting capacity to hot partitions) and split for heat (splitting busy partitions, which only helps if traffic is spread across sort keys rather than a single item). A single item can never exceed those per-partition limits.

Key Points

• Hash of PK chooses the partition.
• ~10 GB, 3,000 RCU and 1,000 WCU per partition.
• Automatic splits; adaptive capacity.
• A single hot key is still capped.

Summary

Single-table design stores several entity types in one table with generic key attributes (PK, SK, GSI1PK, ...) so related items live in the same item collection and can be fetched together in one Query, effectively pre-joining data.

Longer Answer

Pros: fewer round trips (fetch a customer and their recent orders in one request), fewer tables to provision and monitor, and overloaded GSIs serving several patterns.

Cons: a steeper learning curve, harder ad-hoc inspection and analytics, schema changes and new patterns are harder, and per-entity settings (streams, TTL, backups, capacity) apply to everything in the table.

It is a tool, not a rule. Many teams use one table per bounded context or service, and separate tables when entities have different access, scaling or lifecycle needs. Use single-table design where fetching related entities together really matters.

Key Points

• Several entity types, generic key names.
• Related items in one item collection.
• Fewer round trips; harder analytics and evolution.
• Use where it pays off, not by default.

Summary

Query and Scan return at most 1 MB of data per call (before filtering), plus LastEvaluatedKey when there is more. Pass it as ExclusiveStartKey in the next request. Limit caps the number of items evaluated per page.

Longer Answer

Implications:

• A page can contain fewer items than Limit, or even zero items with a LastEvaluatedKey, when a filter expression removes items; keep paging until the key is absent.
• API cursors are usually the encoded LastEvaluatedKey (encrypt or sign it so clients cannot tamper with it).
• There is no "jump to page N"; DynamoDB pagination is cursor-based by nature.
• SDK paginators handle the loop for you.

Key Points

• 1 MB per page; LastEvaluatedKey to continue.
• Filters can produce short or empty pages.
• Cursor-based only.
• Sign cursors exposed to clients.

Summary

Eventually consistent reads (the default) may not reflect a write from the last moment but cost half as much; strongly consistent reads (ConsistentRead: true) return the latest committed write in the Region. GSIs and streams support only eventually consistent reads.

Longer Answer

An eventually consistent read usually catches up within a second. Use strong reads for read-after-write flows where it matters (a user immediately viewing what they saved), or design the UI to use the data already in hand. Strongly consistent reads are not available from a GSI, so a pattern needing them must be served by the base table or an LSI. Global tables have their own cross-Region consistency model.

Key Points

• Eventual (default, half price) vs strong.
• No strong reads on GSIs.
• Strong reads for read-after-write needs.

Summary

On-demand charges per request and scales automatically, suiting new, unpredictable or spiky workloads. Provisioned capacity (usually with auto scaling, optionally with reserved capacity) is cheaper for steady, predictable traffic but can throttle on sudden spikes that auto scaling cannot follow.

Longer Answer

Auto scaling reacts in minutes based on CloudWatch metrics, so short bursts can still throttle a provisioned table. On-demand tables handle large increases quickly but have scaling characteristics of their own (instant accommodation up to roughly double the previous peak), and you can set maximum throughput limits to cap cost.

A common approach: launch on on-demand, observe the traffic shape, and move steady high-volume tables to provisioned with auto scaling and reserved capacity. You can switch modes, with limits on how often.

Key Points

• On-demand: pay per request, spiky/unknown traffic.
• Provisioned + auto scaling: cheaper for steady load.
• Auto scaling lags short spikes.
• Measure, then decide.

Summary

One WCU writes one item of up to 1 KB per second; one RCU performs one strongly consistent read (or two eventually consistent reads) of up to 4 KB per second. Sizes round up, and transactional reads and writes cost twice as much.

Longer Answer

Examples:

• Writing a 3.5 KB item: 4 WCU.
• Strongly reading a 9 KB item: 3 RCU (9/4 rounded up). Eventually consistent: 1.5 RCU.
• Query returning 40 items of 1 KB each: total 40 KB / 4 KB = 10 RCU strongly consistent (queries sum the sizes, then round up), 5 eventually consistent.
• Each GSI adds write units for every write that touches it.

On-demand pricing uses request units with the same size rules. Small items and narrow projections save money.

Key Points

• WCU: 1 KB writes; RCU: 4 KB reads.
• Eventual reads cost half.
• Transactions cost double.
• GSIs add write cost.

Summary

TransactWriteItems and TransactGetItems apply up to 100 actions across items and tables (in one account and Region) atomically: all succeed or none do, with conditions checked as part of the transaction. They cost twice the normal capacity and fail on conflicts with other in-flight transactions.

Longer Answer

Use them for multi-item invariants: transferring a balance between two items, creating an order and decrementing stock together, or enforcing uniqueness of a secondary attribute by writing a separate EMAIL#... item with attribute_not_exists in the same transaction.

Limits: 100 items and 4 MB per transaction, no two actions on the same item, and TransactionCanceledException with per-item reasons when a condition fails or a conflict occurs. Pass a ClientRequestToken to make a retried transaction idempotent (for 10 minutes). Keep most operations single-item where possible; transactions are a tool, not the default.

Key Points

• All-or-nothing across up to 100 items.
• Double capacity cost.
• Uniqueness via extra items.
• ClientRequestToken for idempotent retries.

Summary

DynamoDB only guarantees uniqueness of the primary key. Create a separate item whose key is the unique value (PK = EMAIL#[email protected]) and write it together with the user item in a TransactWriteItems with attribute_not_exists(PK) conditions on both.

Longer Answer

If either condition fails the whole transaction is cancelled, so no duplicate is created even under concurrency. Changing the email means a transaction that deletes the old uniqueness item, creates the new one (with the condition) and updates the user. A GSI on email cannot enforce uniqueness because GSIs allow duplicate keys and update asynchronously.

Key Points

• Only the PK is unique.
• Extra 'uniqueness' item per value.
• Transaction with attribute_not_exists.
• GSIs cannot enforce uniqueness.

Summary

Global tables replicate a table across AWS Regions with every replica accepting reads and writes (multi-active). By default replication is asynchronous, typically within a second or so, and concurrent writes to the same item are resolved by last writer wins. AWS also offers a multi-Region strong consistency mode for global tables with different trade-offs.

Longer Answer

Use cases: low-latency access for users worldwide and Regional disaster recovery. Design implications for the default mode: avoid writing the same item in several Regions at once (route each user's writes to a home Region), make operations commutative or idempotent, and accept that a read in another Region may briefly be stale. Conditional writes and transactions are evaluated only in the Region where they run.

Key Points

• Multi-Region, multi-active replicas.
• Asynchronous by default, last writer wins.
• Route an item's writes to one Region.
• Multi-Region strong consistency option exists.

Summary

Throttling happens when requests exceed provisioned capacity, a partition's limits (hot keys), on-demand scaling limits during a sudden surge, or a GSI's capacity (which back-pressures writes to the table). Clients receive ProvisionedThroughputExceededException or ThrottlingException and should retry with exponential backoff and jitter, which AWS SDKs do automatically.

Longer Answer

Diagnose with CloudWatch metrics (ThrottledRequests, consumed versus provisioned capacity) and Contributor Insights for hot keys. Fixes: better key distribution, higher capacity or on-demand mode, caching, smoothing batch jobs with rate limiting, and sizing GSIs properly. Make sure your own retry layer does not stack on top of the SDK's retries and multiply load.

Key Points

• Capacity, hot partitions, surges, GSIs.
• Exponential backoff with jitter.
• CloudWatch + Contributor Insights.
• Do not double-retry.