In this article
Before you start
This page belongs to the distributed systems interview guide, where DynamoDB is one storage option among several.
Why interviewers ask this
DynamoDB shows up whenever a design needs a store that keeps working as traffic grows, so a candidate who names it has to defend the choice. The follow-up is rarely "what is it". It is usually "what key would you use", "what happens to a popular key", or "is that read up to date".
A weak answer says "it is a scalable database" and stops. A strong answer explains that the key is hashed to pick a partition, names the hot-key failure, and says that reads are eventually consistent by default and that a stronger read costs more. A Staff-level answer adds numbers: how many read units one request uses and what that means for the bill. The back-of-the-envelope estimation guide covers that kind of arithmetic.
DynamoDB from first principles
- Partition key
- A partition key is the one attribute of an item that DynamoDB feeds into an internal hash function to choose the partition where the item is stored. It is either the whole primary key or the first half of a composite key made of a partition key and a sort key.
- Item collection
- An item collection is the set of all items in a table that share the same partition key value. A
Querycan read the whole collection in one operation, and a sort key keeps the items inside it in order. - Secondary index
- A secondary index is an extra key structure over the same items that lets you query by a different key. A local secondary index (LSI) keeps the table's partition key with a different sort key and is created with the table. A global secondary index (GSI) uses a different partition key and is updated asynchronously, so reading it is eventually consistent.
- Read capacity unit
- A read capacity unit (RCU) is the unit in which DynamoDB meters read throughput: one unit pays for one strongly consistent read per second of an item up to four kilobytes (KB), or two eventually consistent reads per second.
In plain words
Picture a wall of lockers in a large station. You never choose a locker. You hand the attendant a ticket number, the attendant runs a fixed rule on the number, and the rule says which locker row holds your bag. Anyone with the same ticket number reaches the same row. DynamoDB works like that: the partition key is the ticket number, and the hash function is the fixed rule.
The analogy breaks in one place: the rows are not in order, so you cannot ask for "all bags between ticket 10 and 20" across the whole wall. Order exists only inside one ticket number's own shelf.
In one precise sentence, DynamoDB places each item by the hash of its partition key, and only items that share a partition key can be read as one ordered range with a Query.
Step 1: The primary key names every item
Every table has a primary key, and there are two shapes. A simple primary key is one attribute called the partition key. A composite primary key is built from two attributes, a partition key and a sort key.
Input: an item. Output: the key that identifies it. In a table that has only a partition key, no two items can share the same partition key value. With a composite key, many items can share the partition key as long as their sort keys differ, which is how one user can own many orders. You now know what identifies an item; next comes where it is stored.
Step 2: The hash of the partition key picks the partition
DynamoDB stores a table in partitions, and a partition is an allocation of storage backed by solid state drives (SSDs) and replicated across multiple Availability Zones in an AWS Region. You never create or move partitions yourself; the service manages them.
To write an item, DynamoDB uses the partition key value as input to an internal hash function, and the output decides the partition. Input: a partition key value. Output: one partition.
The common error follows from this. A hot partition is a partition that receives far more requests than the others because many requests share a few key values, which causes throttling and wastes provisioned capacity. AWS advises a partition key with a large number of distinct values relative to the number of items. A user identifier is a good key; a status code is a bad one. One partition has a ceiling too: AWS states a per-partition limit of 3,000 read units and 1,000 write units per second, so a single hot key value cannot go past it.
Step 3: A query reads one item collection
Because items with one partition key value sit together, you can read multiple items in a single undefined if they share that partition key value. That set is the item collection defined above.
Input: one partition key value and, optionally, a condition on the sort key. Output: the matching items from that collection, in sort-key order. A Scan, by contrast, reads all items in a table and is metered on the size of the items it evaluates, so it costs far more than a Query. Order exists only inside the collection; across the table, items are placed by hash and are not stored in sorted order.
This is why access patterns come first in DynamoDB design. If you cannot say which partition key value each request will supply, the table cannot serve it cheaply. The distributed cache design uses the same hash-to-node idea.
Step 4: A read is eventually or strongly consistent
A DynamoDB item has copies, so a read may reach a copy that has not yet seen the latest write. An eventually consistent read is a read that may return slightly old data but costs less. A strongly consistent read is a read that returns the result of every earlier successful write.
Tables and local secondary indexes (LSIs) offer both options, and eventually consistent is the default. Strongly consistent reads are only supported on tables and LSIs; a read of a global secondary index (GSI) or a stream is always eventually consistent. You request the stronger mode per read with the ConsistentRead parameter. The reason is in the secondary-index definition above: a GSI is updated asynchronously, so it can lag the table, while an LSI shares the table's partition key. DynamoDB also provides read-committed isolation: a read returns a committed value for an item.
Step 5: Capacity units turn each request into a cost
DynamoDB meters work in units, and a table runs in one of two capacity modes. In provisioned mode you set throughput per second: one RCU is one strongly consistent read per second, or two eventually consistent reads per second, for items up to 4 KB. A write capacity unit (WCU) is the matching write unit: one write per second for items up to 1 KB. In on-demand mode you set no rate and pay per read or write request unit, which the Constraints page sizes the same way, 4 KB and 1 KB.
Larger items use more units, and a transactional read costs two read units for an item up to 4 KB. Eventually consistent reads cost half as much as strongly consistent ones, because one unit buys two of them. The worked example below does the rounding.
Step-by-step description
- The key names every item.
- The hash picks the partition.
- A query reads one collection.
- Eventual by default, strong on request.
- Size and mode set the cost.
- The hash of the partition key picks the partition.
- A query reads one item collection.
- A strongly consistent read costs twice an eventually consistent read.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
Capacity arithmetic rounds the item size up to a whole block: 4 KB blocks for reads, 1 KB blocks for writes. A 10 KB item is three 4 KB blocks, so it costs 3 read units for a strongly consistent read, 1.5 for an eventually consistent read and 6 for a transactional read.1 The 4 KB and 8 KB rows follow the documented read costs.
| Item size | Strongly consistent read (RCU) | Eventually consistent read (RCU) | Transactional read (RCU) |
|---|---|---|---|
| 4 KB | 1 | 0.5 | 2 |
| 8 KB | 2 | 1 | 4 |
| 10 KB | 3 | 1.5 | 6 |
Now size a table in provisioned mode. For 100 reads per second of 4 KB items, strongly consistent reads need 100 RCU and eventually consistent reads need 50 RCU; for 100 reads per second of 10 KB items the figures are 300 and 150.1 For writes, a 3.5 KB item rounds up to 4 WCU per write, so 200 such writes per second need 800 WCU (illustrative load).1
Text description of the diagram
- A 10 KB item costs 3 read units strongly consistent and 1.5 eventually consistent.
- A strongly consistent read costs twice an eventually consistent read.
Last, the hot key. Suppose 1,000 writes per second (illustrative) all use one partition key value; that one key takes the whole load. Adding a random or calculated suffix to the key spreads them over 10 values (illustrative), so each value takes 100 writes per second.1 At 1 KB per item, 1,000 writes per second is 1,000 write units on one key, exactly the per-partition write ceiling quoted in Step 2, which is why the suffix helps.1
Trade-offs and edge cases
DynamoDB trades flexible queries for predictable speed. You get fast lookups by key and by key range inside one collection, but anything that is not a key lookup needs another key design or an index.
- Global index reads are never strong. A GSI read is always eventually consistent, so a design that must read its own write through an index needs another route, such as reading the table.
- Strong consistency is not free. It uses twice the read units, as the worked example shows.
- Write sharding moves the cost to readers. The suffix spreads writes, but a reader must now look at every suffix value to see all items of the logical key. This follows from the method in the write-sharding guidance.
- Items are small. The maximum item size is 400 KB, counting attribute names as well as values, so large blobs belong in other storage.
- A hot key has a hard ceiling. DynamoDB's adaptive capacity can shift capacity toward busy partitions, but one key value still cannot exceed the per-partition limit in the partition-key guidance, so the fix is a better key or a suffix.
- Global tables relax freshness across Regions. A global table is a set of replicas of one table in several Regions. In the default mode, item changes are replicated typically within a second and are eventually consistent across Regions; a multi-Region strong consistency (MRSC) mode also exists.
Text description of the diagram
- Tables and local secondary indexes support strongly consistent reads.
- Reads from global secondary indexes and streams are always eventually consistent.
For a payment flow or a rate limiter, the consistency choice matters most; see the payment system design and the distributed rate limiter walkthroughs.
How to answer it in an interview
What is DynamoDB and how would you use it?
DynamoDB is a managed Amazon database where I choose a partition key, and it hashes that key to pick the partition, so lookups by key stay fast as data grows. I would pick a key with many distinct values, like a user identifier, because a popular key becomes a hot partition and throttles. Reads are eventually consistent by default; I can ask for a strongly consistent read on the table, but it costs twice the read units, and reads from a global secondary index are always eventually consistent. I would size capacity from item size.
The spoken structure: define it, name the key and its failure, give the consistency trade-off, then close with cost.
Common mistakes
- "DynamoDB is always eventually consistent." (wrong) That is only the default. (right) "Reads are eventually consistent by default, and I can request a strongly consistent read on a table or local secondary index."
- "I will make the read strongly consistent on the global secondary index." (wrong) Index and stream reads are always eventually consistent. (right) "I will read the table when I need the latest value."
- "I will pick the status as the partition key." (wrong) Few distinct values create hot partitions. (right) "I will pick a high-cardinality key such as the user identifier."
- "I manage the physical partitions myself." (wrong) The service partitions for you; key suffixes are an application-level choice, not partition management. (right) "I only choose the key, and a suffix if needed; DynamoDB handles the partitions."
- "The 400 KB limit counts only values." (wrong) Attribute names count too. (right) "Names and values both count toward the limit."
Follow-up questions
What is a hot partition in DynamoDB and how do you fix it?
A hot partition is a partition that gets far more traffic than the rest because a few key values dominate. Pick a key with many distinct values, or spread writes by adding a random or calculated suffix to the key, as the write-sharding guidance describes.
Is DynamoDB strongly consistent?
Not by default. Reads are eventually consistent unless you ask for a strongly consistent read, which tables and local secondary indexes support. Writes are acknowledged only after they are durably stored, as the read-consistency page describes.
Can you read a global secondary index with a strongly consistent read?
No. All reads from global secondary indexes and streams are eventually consistent, so read the table when the freshest value matters.
How much does one DynamoDB read cost?
For an item up to 4 KB, one read unit when strongly consistent, half a unit when eventually consistent and two when transactional. Larger items round up to the next 4 KB block.
What is the maximum item size in DynamoDB?
400 KB, and the count includes attribute names as well as values.
For the wider set of storage questions, see the backend interview questions.
- DynamoDB hashes the partition key to choose the partition; you never manage partitions.
- Choose a key with many distinct values, or a hot partition throttles the table.
- A
Queryreads one item collection, ordered by the sort key. - Reads are eventually consistent by default; strong reads cost twice as much and are unavailable on indexes of the global kind.
- Costs round item size up to 4 KB for reads and 1 KB for writes.
Sources
- What is Amazon DynamoDB? — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
- Using global secondary indexes in DynamoDB — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
- Best practices for designing and using partition keys effectively — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
- DynamoDB read consistency — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
- Partitions and data distribution in DynamoDB — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
- Constraints in Amazon DynamoDB — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
- DynamoDB read and write operations — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
- Designing partition keys to distribute your workload in DynamoDB — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
- Core components of Amazon DynamoDB — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
- Using write sharding to distribute workloads evenly — Amazon Web Services (DynamoDB Developer Guide), 26 Oct 2026
