Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
DynamoDB single-table design is a sophisticated data modeling technique where multiple entity types are stored within a single table to optimize for specific read and write access patterns. Unlike relational databases that rely on normalization and JOINs, single-table design leverages composite primary keys and Global Secondary Indexes (GSIs) to retrieve related data in a single request. In 2026, this remains the gold standard for high-scale, low-latency applications on AWS, as it minimizes network round-trips and maximizes throughput. Interviewers ask about this topic to evaluate a candidate's ability to move beyond SQL-centric thinking, demonstrating deep understanding of distributed systems, partition key distribution, and the trade-offs between storage efficiency and query performance. Junior engineers are expected to explain the basic mechanics of partition and sort keys, while senior engineers must articulate complex strategies like GSI overloading, sparse indexes, and handling data skew in high-concurrency environments.
Single-table design is critical because DynamoDB's performance is tied to the efficiency of its underlying storage engine. In a distributed key-value store, JOIN operations are not supported; therefore, if your data model requires fetching related entities, you must either perform multiple round-trips or co-locate that data. By using a single table, you can model one-to-many and many-to-many relationships using sort key prefixes and GSI projections, enabling 'single-request' retrieval. This is essential for latency-sensitive applications like real-time gaming, ad-tech, or high-frequency financial platforms where every millisecond counts. A strong candidate understands that this approach is not just about 'putting everything in one bucket,' but about mapping business requirements to the physical storage layout. Weak answers often suggest 'denormalization' without explaining the specific impact on partition key distribution or the cost implications of GSI writes. In 2026, with the rise of serverless architectures, the ability to design cost-effective, scalable DynamoDB schemas is a high-signal skill that differentiates architects from developers who treat NoSQL as a simple key-value store.
DynamoDB uses a partition-based architecture where data is distributed across nodes based on the hash of the Partition Key. In single-table design, the application layer acts as the orchestrator, mapping business entities to specific PK/SK structures. When a query is executed, the request hits the Request Router, which identifies the partition, then retrieves the data from the storage engine. GSIs are maintained asynchronously, meaning writes to the base table trigger updates to the indexes.
[Client Request]
↓
[Request Router]
↓
[Partition Map]
↓ ↓
[Node A] [Node B]
↓ ↓
[Table] [GSI]
↓ ↓
[Storage] [Index]Using prefixes like 'USER#', 'ORDER#', 'PRODUCT#' in the SK to distinguish entity types within the same partition.
Trade-offs: Improves readability and query filtering but requires careful string management.
Mapping multiple entity attributes to generic index fields like GSI1PK and GSI1SK.
Trade-offs: Reduces index count and cost but complicates application-level logic.
Only writing to an index if a specific attribute exists, reducing index size.
Trade-offs: Saves storage and write costs but limits the index to specific use cases.
| Reliability | Use DynamoDB Streams to replicate data or trigger downstream processes; implement exponential backoff for retries. |
| Scalability | Use On-Demand capacity for unpredictable workloads or Auto-Scaling for predictable ones; ensure partition keys have high cardinality. |
| Performance | Target single-digit millisecond latency; use DAX for read-heavy workloads; keep items small. |
| Cost | Use GSI overloading to reduce index count; leverage S3 for large data; monitor 'ConsumedCapacity' metrics. |
| Security | Use IAM policies with condition keys to restrict access to specific items or attributes; enable encryption at rest. |
| Monitoring | Track 'ThrottledRequests', 'ConsumedReadCapacityUnits', and 'ConsumedWriteCapacityUnits' in CloudWatch. |
No. Single-table design is optimized for specific, high-scale access patterns. If your application requires ad-hoc querying, complex reporting, or has low traffic, a normalized multi-table approach or a relational database may be more appropriate and easier to maintain.
DynamoDB does not support foreign key constraints. Data integrity must be managed at the application layer using transactions (TransactWriteItems) or by designing the schema to ensure related items are updated atomically.
A GSI can have a different partition key than the base table and is eventually consistent. An LSI must share the same partition key as the base table but allows a different sort key and supports strongly consistent reads.
No. DynamoDB does not support JOIN operations. You must model your data to co-locate related items in the same partition or perform application-level joins, which is why single-table design is so critical.
Schema migrations are challenging. Use techniques like 'Expand and Contract' (adding new attributes, updating code to handle both, then removing old ones) and leverage DynamoDB Streams to update existing items in the background.
It is a pattern because it allows developers to reuse a limited number of indexes to support many different query shapes, effectively reducing the write-cost overhead associated with maintaining multiple indexes for every entity type.
A hot partition occurs when a specific partition key receives a disproportionate amount of traffic, causing throttling. This is usually due to poor key design, such as using a low-cardinality attribute like 'Status' as the partition key.
Generally, no. It can actually decrease storage costs by reducing the number of indexes. However, if you project too many attributes into GSIs, you will increase both storage and write costs significantly.
Use the adjacency list pattern. Store both directions of the relationship. For example, to find all users in a group and all groups for a user, store both (PK: GROUP#ID, SK: USER#ID) and (PK: USER#ID, SK: GROUP#ID).
The sort key enables range queries and hierarchical data organization. By using prefixes, you can store different entity types in the same partition and query them efficiently using range operators like 'begins_with'.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.