Top 60 DynamoDB Interview Questions (2026)

DynamoDB is a fully managed NoSQL database from AWS that stores key-value and document data and returns it with single-digit millisecond latency at almost any scale. It's serverless, so there's no cluster to run, patch, or replicate.

It solves the problem of predictable performance under unpredictable load. You get consistent latency whether the table holds a thousand items or a billion, and throughput scales without downtime. The cost is that you design around known access patterns instead of running ad-hoc queries.

A relational database organizes data into tables with fixed schemas and lets you join and query freely with SQL. DynamoDB stores schemaless items, has no joins, and is built to serve a known set of access patterns fast.

The mental shift is that you model for the query in DynamoDB. Instead of normalizing and joining at read time, you shape the data so the reads you need are single, cheap lookups.

A simple primary key is just a partition key (also called a hash key). A composite primary key is a partition key plus a sort key (also called a range key).

With a simple key, each item is found by one value. With a composite key, many items can share a partition key and are stored together, sorted by the sort key, which is what makes range queries within a partition efficient.

DynamoDB hashes the partition key value and uses the result to decide which physical partition stores the item. All reads and writes for that item route to the same partition.

That's why partition key choice matters so much: if many requests target the same key value, they all hit one partition and you get throttling. Spreading traffic across many distinct key values keeps load balanced.

A sort key orders items that share a partition key. Within one partition key, items are stored sorted by the sort key, so you can fetch ranges: all orders for a user between two dates, the latest N events, everything with a given prefix.

Sort keys are where a lot of modeling power lives. Prefixing sort key values (like ORDER#2026 or PROFILE#) lets one table hold different item types under the same partition key and query them selectively.

Query fetches items for a specific partition key, optionally narrowed by a sort key condition. It only reads matching items, so it's fast and cheap. Scan reads every item in the table and then applies filters, so it gets slower and more expensive as the table grows.

The rule in interviews: design so you Query, and treat Scan as a smell. A filter expression on a Scan still charges you for every item read, not just the ones returned.

A strongly consistent read returns the most recent data, reflecting every successful write before it. An eventually consistent read might return slightly stale data because it can be served from a replica that hasn't caught up yet, usually within a second.

Eventually consistent reads are the default and cost half as much. Ask for strong consistency only when reading your own recent write matters, like showing a value the user just saved.

An item is a single record, like a row. An attribute is a name-value pair inside an item, like a column value. Every item must have the table's primary key attributes; everything else is optional and can differ item to item.

This is the schemaless part: two items in the same table can hold completely different attributes as long as both carry the primary key. That flexibility is what makes single-table designs possible.

Scalars: string (S), number (N), binary (B), boolean (BOOL), and null (NULL). Documents: list (L) and map (M) for nested structures. Sets: string set (SS), number set (NS), and binary set (BS) for unique collections.

Numbers are stored as a single type with high precision, so there's no separate int and float. Sets can't be empty and can't hold duplicates, which trips people up when they expect list behavior.

PutItem writes or fully replaces an item by primary key. GetItem reads one item by its full primary key. Both are the cheapest, fastest operations because they touch exactly one item on one partition.

PutItem overwrites the whole item if the key already exists. To change only some attributes, use UpdateItem instead, which modifies named attributes without replacing the rest.

UpdateItem changes named attributes on an existing item and leaves the rest untouched; it creates the item if it doesn't exist. PutItem replaces the entire item, dropping any attributes you didn't include.

UpdateItem also does atomic operations in place: incrementing a counter, adding to a set, appending to a list, all without reading first. That avoids a read-modify-write race.

Provisioned mode has you set read capacity units and write capacity units up front; you pay for that reserved throughput whether you use it or not, and it's cheaper for steady, predictable load. On-demand mode charges per request with no planning and scales instantly, which fits spiky or new workloads.

A common answer: start on-demand while traffic is unknown, then switch to provisioned with auto scaling once the pattern is clear and you want lower cost.

A Read Capacity Unit is one strongly consistent read per second of an item up to 4 KB, or two eventually consistent reads. A Write Capacity Unit is one write per second of an item up to 1 KB. Bigger items consume more units, rounded up.

So a 10 KB item costs 3 RCUs for a strongly consistent read (10 KB rounds to 3 blocks of 4 KB) and 10 WCUs to write. Knowing the rounding is what interviewers check.

DynamoDB throttles the request and returns a ProvisionedThroughputExceededException. The AWS SDKs catch that and retry the throttled request automatically with exponential backoff and jitter, so short spikes usually recover on their own and your application never sees an error surface.

Sustained throttling means you're under-provisioned or you have a hot partition sending too much traffic to one key. The fix is more capacity, auto scaling, or a better-distributed partition key.

A GSI is an index with its own partition key and optional sort key, different from the base table's keys. It lets you query by attributes that aren't the primary key. DynamoDB keeps the index in sync automatically as the base table changes.

GSIs are always eventually consistent and have their own capacity. You choose which attributes get projected into the index, which controls its size and whether reads need to fetch back from the base table.

An LSI shares the base table's partition key but uses a different sort key, giving you an alternate sort order within each partition. Unlike a GSI, it can be read with strong consistency.

The catches: an LSI must be created when the table is created and can't be added later, and it shares the partition's throughput and the 10 GB per-partition-key size limit. Most designs reach for a GSI instead.

BatchGetItem reads up to 100 items across one or more tables in a single call. BatchWriteItem puts or deletes up to 25 items per call. Both cut round trips, which lowers latency when you're moving many items.

They aren't transactions: individual items can fail and come back as unprocessed, so you retry those. If you need all-or-nothing, use the transaction APIs instead.

Many attribute names collide with DynamoDB reserved words (name, status, size, count, and hundreds more). Using one directly in an expression throws an error. Expression attribute names, the placeholders starting with #, let you reference them safely.

The habit worth forming: use #name placeholders for attributes and :val placeholders for values in every expression, so reserved words and injection are never a problem.

A single item can be at most 400 KB, counting every attribute name and value, including nested lists and maps. That limit is hard, so a design that grows an item without bound eventually fails a write, which is why blobs don't belong inside the item.

For anything bigger, store the blob in S3 and keep only the S3 key plus metadata in the DynamoDB item. This keeps items small, reads cheap, and sidesteps the limit entirely.

TTL lets you mark an attribute holding a Unix timestamp as an expiry field. DynamoDB deletes items automatically after that time, at no extra cost, without consuming write capacity for the deletion.

It's the right tool for sessions, temporary tokens, and event data with a natural lifespan. Deletion isn't instant; items expire within a window after their timestamp, so don't rely on it for exact-second cleanup.

Single-table design stores multiple entity types (users, orders, products) in one table, using key prefixes and overloaded keys to keep related items together and serve many access patterns from one table.

The reason is performance and cost: one Query can fetch a user and all their orders in a single request if they share a partition key, instead of joining across tables. The cost is complexity; the design is harder to read and change later.

In a relational database you model the data, then write queries. In DynamoDB you list the queries first, then design keys and indexes so each query is a single efficient lookup. The schema serves the access patterns, not the other way around.

This is why the first modeling question in an interview is usually 'what are your access patterns?'. If you design keys before listing reads and writes, you end up needing Scans, which defeats the point of the database.

A hot partition happens when one partition key value gets far more traffic than others, so requests concentrate on a single partition and throttle even though the table has spare capacity overall.

You avoid it by choosing a high-cardinality partition key that spreads traffic evenly, and by adding a random or calculated suffix (write sharding) when one logical key is unavoidably hot, like a viral item's counter.

Choose a GSI in almost every case: it can use any attribute as its key, can be added after the table exists, and has independent capacity. Choose an LSI only when you need strong consistency on the alternate sort order and you know the requirement at table-creation time.

The LSI constraints are real deal-breakers: it must exist from creation, shares the base partition's throughput, and forces the partition's items under a 10 GB limit. That's why most teams standardize on GSIs.

A GSI projects a copy of chosen attributes. KEYS_ONLY projects just the keys, INCLUDE projects the keys plus named attributes, and ALL projects every attribute. More projection means a bigger, more expensive index but reads that don't fetch back from the base table.

The judgment call: project exactly what the index's queries return. Under-project and every read pays a second lookup against the base table; over-project and you pay storage and write cost for attributes nobody queries there.

A conditional write only succeeds if a condition expression is true, checked atomically on the item. It's how you prevent overwriting newer data, enforce uniqueness, or implement optimistic locking without a read-then-write race.

The classic uses: attribute_not_exists(pk) to create an item only if it's new, and a version check to make sure nobody changed the item since you read it.

TransactWriteItems and TransactGetItems group up to 100 actions across one or more tables into an all-or-nothing operation with ACID guarantees. If any condition fails or any item conflicts, the whole transaction rolls back.

Transactions cost twice the capacity of the equivalent single operations, because DynamoDB does a prepare and a commit phase. Use them for genuine multi-item invariants, like transferring a balance, not for routine writes.

DynamoDB Streams captures an ordered log of every item-level change (insert, update, delete) and keeps it for 24 hours. You configure what the record contains: keys only, the new image, the old image, or both.

The common pattern is a Lambda triggered per change for replication, search indexing, notifications, aggregations, or maintaining a materialized view. It's how you react to writes without polling the table.

DAX is an in-memory cache built for DynamoDB that cuts read latency from single-digit milliseconds to microseconds for cache hits. It's API-compatible, so app code barely changes, and it handles read-through caching for you.

It fits read-heavy workloads with repeated reads of the same items. It doesn't help write-heavy patterns, and because it's a cache, reads through it are eventually consistent; strongly consistent reads bypass DAX and hit the table.

A single Query or Scan returns at most 1 MB of data. If more matches exist, the response includes a LastEvaluatedKey. You pass it back as ExclusiveStartKey to fetch the next page, looping until the key is absent.

This means results are naturally paginated even when your filter matches a lot. Forgetting the loop is a classic bug: you process one page and think that's the whole result set.

Adaptive capacity lets DynamoDB shift unused throughput toward partitions that need it and isolate a hot partition key onto its own partition. It smooths out uneven access automatically, so mild skew no longer causes throttling the way it once did.

It's automatic and free, but it's not a cure for a badly chosen partition key. Sustained heavy skew on one value still needs a better key or write sharding; adaptive capacity buys headroom, not immunity.

GSI overloading reuses one generic index across many entity types by storing different meanings in the same index key attributes per item. A single GSI can then serve several access patterns instead of creating one index per pattern.

It keeps you under the index limit and cost down, at the price of readability. The keys hold values like TYPE#STATUS that only make sense with the design in front of you, so document it well.

A sparse index only contains items that actually have the index's key attribute set. Items missing that attribute never make it into the index at all, so the index stays small, cheap, and fast to query even when the base table holds millions of items you don't care about.

It's the efficient way to query a subset. Set the GSI key only on items you want to find, like adding an attribute openTickets only to unresolved tickets, and the index becomes a ready-made filtered view.

Start from item size and request rate. For writes, divide item size by 1 KB (round up) and multiply by writes per second to get WCUs. For reads, divide by 4 KB (round up) for strongly consistent, then halve for eventually consistent, multiplied by reads per second.

Then add headroom for spikes and remember transactions and GSIs consume their own capacity. Getting the rounding and the read-vs-write divisors right is the whole point of the question.

Separate retryable from non-retryable. Throttling and internal server errors are retryable with exponential backoff and jitter, which the AWS SDKs do by default. Validation errors, conditional check failures, and access-denied are not; retrying just repeats the failure.

For batch operations, always process the UnprocessedItems or UnprocessedKeys the response returns, re-sending only those with backoff. Ignoring them silently drops data.

On-demand backups take a full snapshot you keep as long as you want. Point-in-time recovery (PITR) continuously backs up the table so you can restore to any second in the last 35 days, which protects against accidental writes and deletes.

Both restore into a new table rather than overwriting the original, so you validate before switching over. PITR is the one to enable on anything important; the continuous coverage is worth the small cost.

Global tables replicate one table across multiple AWS regions with active-active writes, so users in every region read and write against their nearest copy with low latency, and each change propagates out to the other regions automatically without you running any replication yourself.

Replication is asynchronous and eventually consistent across regions. Concurrent writes to the same item in different regions are resolved last-writer-wins by timestamp, so design so a given item is usually written in one region to avoid surprises.

A FilterExpression runs after DynamoDB reads the items, so you're charged for every item Query or Scan reads, not the smaller set the filter returns. It reduces network payload, not cost.

The lesson is to filter with keys, not with FilterExpression. Put the filtering attribute into the sort key or a GSI so the read only touches matching items in the first place.

A table can have up to 20 global secondary indexes and up to 5 local secondary indexes by default. Once you hit that ceiling you either overload a single index to serve several access patterns or rethink the model, because you can't just keep adding one index per query forever.

Each GSI also costs write capacity, because every base-table write that touches a projected attribute writes to the index too. So indexes aren't free; more of them means higher write cost and more moving parts, which is why overloading exists.

DynamoDB Local is a downloadable version that runs on your machine or in a container, speaking the same API. You point the SDK at the local endpoint, so tests run fast and offline with no AWS charges.

It's close enough for functional tests of your queries and writes. It doesn't model real capacity, throttling, or multi-region behavior, so load and consistency edge cases still need a real table.

DynamoDB hashes each item's partition key to place it on one of many physical partitions, each holding up to 10 GB and a fixed throughput ceiling (roughly 3,000 RCUs and 1,000 WCUs). As data or throughput grows past a partition's limits, DynamoDB splits it and redistributes items automatically.

This is why partition key cardinality drives performance: traffic is only as balanced as the keys are distributed. A partition split is transparent, but the per-partition ceilings explain why one hot key throttles even on a large, well-provisioned table.

Use the adjacency list pattern: store each relationship as its own item, and use a GSI to traverse it in both directions. A user-in-groups example stores a membership item per pair, keyed so you can query all groups for a user and, via the GSI, all users in a group.

There are no join tables that get joined at read time. You precompute the relationship as items and read each direction as a single Query, which is the whole trick of relational modeling in a key-value store.

Every write is synchronously replicated to multiple storage nodes across three Availability Zones before it's acknowledged, which is what makes writes durable. A write succeeds once a quorum of replicas has it.

A strongly consistent read is routed to the leader replica that has every acknowledged write; an eventually consistent read may hit a follower that's milliseconds behind. That leader-vs-follower routing is the mechanism behind the consistency choice you make per read.

Attack the biggest levers: switch spiky tables to on-demand and steady ones to provisioned with auto scaling, shrink items (short attribute names, move blobs to S3), and prune GSIs and their projections since each write fans out to them.

Then reduce work: replace Scans with Queries or GSIs, use eventually consistent reads where staleness is fine to halve read cost, cache hot reads with DAX, and set TTL to expire data instead of paying to store and scan it. Measure with CloudWatch and Cost Explorer before and after.

First confirm it with CloudWatch Contributor Insights to see which key is hot. Then, in order of effort: rely on adaptive capacity for mild cases, put a cache (DAX or an application cache) in front of read-heavy hot items, and write-shard the key by appending a suffix so writes spread across partitions, reading by summing the shards.

For a monotonically increasing counter, the shard-and-sum pattern is the standard fix. The judgment is matching the tool to whether the heat is reads (cache) or writes (sharding).

Streams give ordered, at-least-once delivery per shard, so your consumer must be idempotent: the same change record can arrive twice, and processing it twice must be safe. Key your downstream writes on the item's identity plus a version or sequence number so replays are no-ops.

Also handle failure without blocking the shard: a poison record that keeps failing stalls everything behind it in that shard, so use a retry limit and a dead-letter queue. Order is only guaranteed within a shard, not across the whole table.

Start from access patterns, not the existing schema. Catalog every query the relational app runs, then design DynamoDB keys and GSIs to serve them, denormalizing where a join used to be. The relational schema is a starting inventory, not a template.

For the move itself: dual-write or backfill with a controlled job, verify with shadow reads comparing both stores, then cut over. Use DynamoDB Streams to keep derived data in sync during the transition. The hard part is the modeling shift, not the data transfer.

Write sharding appends a suffix (random 0..N or a hash) to a partition key that would otherwise be hot, spreading writes across N partitions. A viral post's like counter, for example, becomes N counter items instead of one contended item.

The cost lands on reads: to get the true value you must read all N shards and combine them, turning one GetItem into N reads plus aggregation. So you shard only as wide as the write pressure needs, because every extra shard is another read every time.

Yes. In provisioned mode, if a GSI runs out of write capacity, back-pressure propagates and base-table writes that update the index start throttling too, because DynamoDB won't let the index fall arbitrarily behind.

The fixes: provision GSI capacity to match the base table's write rate on projected attributes, or use on-demand so both scale together. Projecting fewer attributes also helps, since a write only touches the index if it changes a projected attribute.

Split the data. Move large blobs (documents, images, big JSON) to S3 and store only the S3 key and metadata in DynamoDB. For large structured records, break them into multiple items under one partition key so a Query reassembles them, keeping each item small.

Vertical partitioning also helps: put rarely read big attributes in a separate item so the hot path reads a small item. The goal is small items on the read path, because item size drives both RCU cost and latency.

Keep a version attribute on the item. On update, condition the write on the version matching what you read, and increment it in the same call. If another writer got in first, the version won't match and the conditional write fails, so you re-read and retry.

This gives safe concurrent updates without a lock service. It's the right tool when conflicts are rare; under heavy contention on one item, the retries pile up and you're back to a hot-key problem.

Partition by a time bucket plus an entity so writes spread over time instead of hammering one key. A common shape is partition key like DEVICE#123#2026-07 and a sort key of the exact timestamp, so a month's readings live together and range queries by time are cheap.

Pair it with TTL to expire old data automatically, and consider rolling old buckets to cheaper storage. The anti-pattern is a single partition key for all events, which turns the newest bucket into a permanent hot partition.

Assume a read right after a write might not see it, especially on GSIs, which are always eventually consistent. Design flows so the user isn't blocked on immediate read-after-write: return the value you just wrote from memory instead of re-reading, or use a strongly consistent read on the base table for that one path.

For derived data built from Streams, embrace the lag and make consumers idempotent. The failure mode is UI that reads a GSI immediately after a write and shows stale data; route that specific read to the base table with strong consistency.

Both are partitioned, high-throughput NoSQL stores with similar data models, and DynamoDB's design descends from the original Dynamo paper. The real difference is operations: DynamoDB is fully managed and serverless, while Cassandra is a cluster you run, tune, and scale yourself.

Pick DynamoDB when you want zero operational overhead and are in AWS. Pick Cassandra when you need multi-cloud or on-prem control, want to avoid vendor lock-in, or have the team to operate a cluster and want to tune replication and consistency yourself.

Watch ThrottledRequests and the throttle events split by read and write to catch capacity or hot-key trouble early, consumed vs provisioned capacity to size correctly, and SuccessfulRequestLatency to spot degradation. Contributor Insights surfaces the most-accessed keys, which is how you find a hot partition before users do.

For GSIs, monitor their consumed capacity separately, since a starved index can throttle base writes. Alarm on sustained throttling rather than single spikes, because the SDK's backoff absorbs brief ones.

List access patterns first: create a short code, resolve a short code to its long URL, and maybe list a user's links. Then the table is simple: partition key is the short code, attributes are the long URL, owner, and created time. Resolution is a single GetItem, which is exactly the cheap lookup DynamoDB is built for.

For code generation, avoid a global counter (a hot key); generate a random code and use a conditional PutItem with attribute_not_exists to guarantee uniqueness, retrying on the rare collision. Add a GSI on owner for the list-my-links pattern, cache hot codes with DAX or a CDN, and use on-demand capacity to ride traffic spikes.

Find every Scan and the query it's really trying to answer, then serve that query with keys or a GSI instead. If code scans and filters by status, add a GSI keyed on status (or a sparse index for the subset) so the same result is a Query that reads only matching items.

Roll it out safely: add the index, backfill it, switch reads over, verify results match, then delete the Scan path. Where a full-table read is genuinely needed (a nightly export), use a parallel Scan with segments, but treat that as the exception.

Prefix the partition key with a tenant ID (TENANT#42#...) so each tenant's data is naturally isolated and every query is scoped to one tenant. Enforce it with IAM condition keys that restrict a caller to items whose partition key begins with their tenant, so isolation holds even if app code has a bug.

Watch for a large tenant becoming a hot partition; shard their keys if needed. For strict isolation or wildly different sizes, a table per tenant is an option, at the cost of more tables to manage. The pooled single-table model is the common default.

The ones that bite: you can switch between capacity modes only once every 24 hours, a partition holds at most 10 GB per partition key value under an LSI, item size caps at 400 KB, and Streams retain records for just 24 hours so a stalled consumer loses data.

Also, transactions and strongly consistent reads cost more capacity than their basic equivalents, and adding an LSI is impossible after table creation. Knowing these before they surprise you in an incident is what production experience buys.

When access patterns are unknown or keep changing, DynamoDB's up-front modeling works against you; a relational database's ad-hoc queries fit better. It's also wrong for heavy analytics, reporting with joins and aggregations, and full-text search, which belong in a warehouse or a search engine.

The production signal is refusing to treat it as a default. DynamoDB shines for known, high-scale, low-latency patterns; recommending Postgres or OpenSearch when those fit better is the answer that shows judgment rather than allegiance.