This chapter covers DynamoDB, a managed NoSQL service designed for high availability, strong durability, and scalability, meeting diverse data management needs.

System Design

Amazon DynamoDB

Efficiently prepare for coding interviews with strategies from FAANG engineers. Avoid the LeetCode grind and simplify your interview prep with real-world questions from top companies.

Coding

The ultimate guide to the System Design Interview – developed by Meta & Google engineers. Master distributed system fundamentals, and practice with real-world interview questions & mock interviews.

The essential guide to API Design & Product Design Interviews – developed by FAANG engineers. Master product design fundamentals & get hands-on with real-world APIs.

API Design

A battle-tested guide to Object Oriented Design Interviews – developed by FAANG engineers. Master OOD fundamentals & practice real-world interview questions.

Low Level Design Interview Using OOD Principles

Your essential EM Interview crash course. Learn strategies from FAANG hiring managers to demonstrate your leadership skills & experience to interviewers.

Engineering Management and Leadership Interviews

The ultimate guide to behavioral interviews. Developed by FAANG engineers. Use real-world questions, video recording, and structured strategies to get interview-ready in just a few hours.

Behavioral

The multi-tenant architecture allows us to use our resources efficiently. Dedicating one node for one table could result in underutilization if the table contains a limited amount of data. To scale the table, we might need to dedicate another node if the first node cannot store all the table's data. One node dedicated to the table is utilized well, while the other could be underutilized. The multi-tenant architecture allows us to spread our tables across our network as partitions, thus spreading the potential effect of underutilizing dedicated resources.

Multi-tenant architecture also enables easy scaling since we can allocate and deallocate resources at the partition level.

The multi-tenant architecture allows us to use our resources efficiently. Dedicating one node for one table could result in underutilization if the table contains a limited amount of data. To scale the table, we might need to dedicate another node if the first node cannot store all the table’s data. One node dedicated to the table is utilized well, while the other could be underutilized. The multi-tenant architecture allows us to spread our tables across our network as partitions, thus spreading the potential effect of underutilizing dedicated resources.
Multi-tenant architecture also enables easy scaling since we can allocate and deallocate resources at the partition level.

How does our design take advantage of the multi-tenant architecture?

How does our design take advantage of the multi-tenant architecture?

If an application can utilize a NoSQL solution well, it is more efficient and available than traditional databases (which are harder to scale over geographically dispersed sites).

1. NoSQL allows unstructured and semi-structured data, allowing a wider range of use cases.
2. We can store data from multiple tables of an RDBMS in a single NoSQL document.
3. NoSQL is easier to scale than an RDBMS.
4. NoSQL data models are optimized for performance, especially when replicas are far away.
5. The NoSQL model allows node replacement without downtime.

If an application can utilize a NoSQL solution well, it is more efficient and available than traditional databases (which are harder to scale over geographically dispersed sites).
<ol>
<li>NoSQL allows unstructured and semi-structured data, allowing a wider range of use cases.</li>
<li>We can store data from multiple tables of an RDBMS in a single NoSQL document.</li>
<li>NoSQL is easier to scale than an RDBMS.</li>
<li>NoSQL data models are optimized for performance, especially when replicas are far away.</li>
<li>The NoSQL model allows node replacement without downtime.</li>
</ol>

Why have we chosen a NoSQL database over a relational database?

Why have we chosen a NoSQL database over a relational database?

In practice, keys are not accessed uniformly. This could result in some partitions having underutilized throughput, while some may face a shortage of throughput.

In practice, keys are not accessed uniformly. This could result in some partitions having underutilized throughput, while some may face a shortage of throughput.

What problem occurs during the uniform distribution of provisioned throughput for a table across partitions?

What problem occurs during the uniform distribution of provisioned throughput for a table across partitions?

Bursting should only take place when there is workload isolation between co-resident partitions. This means that allowing the bursting partition to utilize extra throughput should not impact other tenants (who might be residing on the same physical node).

Bursting should only take place when there is workload isolation between co-resident partitions. This means that allowing the bursting partition to utilize extra throughput should not impact other tenants (who might be residing on the same physical node).

What is an important factor to consider when bursting a partition?

What is an important factor to consider when bursting a partition?

First, we need to detect such pathological cases where spikes on a table partition are moving around very fast, and there is no fixed pattern of access.

We might put multiple partitions of this specific tenant on the same nodes so that as spikes move around, the same local node could serve it (instead of moving the partition around). Additionally, doing so isolates other tenants from such access patterns.

This might be a case where our system alone can't solve the problem, and we need cooperation from the client's application. Altering the application's access pattern might be one strategy. If nothing works, the client might need over-provisioning of resources.

We encourage you to think about how such a use case can be managed (remember that there are always multiple ways to solve the same problem, and as designers, we should be able to evaluate them).



First, we need to detect such pathological cases where spikes on a table partition are moving around very fast, and there is no fixed pattern of access.
We might put multiple partitions of this specific tenant on the same nodes so that as spikes move around, the same local node could serve it (instead of moving the partition around). Additionally, doing so isolates other tenants from such access patterns.
This might be a case where our system alone can’t solve the problem, and we need cooperation from the client’s application. Altering the application’s access pattern might be one strategy. If nothing works, the client might need over-provisioning of resources.
We encourage you to think about how such a use case can be managed (remember that there are always multiple ways to solve the same problem, and as designers, we should be able to evaluate them).

Assume that a tenant workload is fluctuating heavily across many keys. This means that while throughput provision is enough overall, it is not enough for specific partitions on specific nodes.

How can we manage such a case in our system?

Assume that a tenant workload is fluctuating heavily across many keys. This means that while throughput provision is enough overall, it is not enough for specific partitions on specific nodes.
How can we manage such a case in our system?

Test your understanding of concepts related to the design of DynamoDB via a quiz.

__default

Quiz on DynamoDB