Database Reference
In-Depth Information
Chapter 3. How DynamoDB Works
In the previous chapter, we saw the features DynamoDB has, and learned how to perform
various operations on DynamoDB using a variety of APIs. We also saw various
application-oriented examples, and what features of DynamoDB fit well in what condi-
tions. Now it's time to understand its internals. In this chapter, we are going to talk about
why DynamoDB was developed. What is the architecture underneath that makes it so ro-
bust and scalable? How does DynamoDB handle failures? So, let's get started.
In Chapter 1 , Getting Started , we discussed DynamoDB's history; DynamoDB was built to
address the scaling needs of Amazon's worldwide e-commerce platform, and also provide
high availability, reliability, and performance. Amazon's platform is highly decoupled, con-
sisting of thousands of services running on storage machines. Amazon needs reliable stor-
age systems that can store and retrieve data even in conditions like disk failures, network
failures, or even during natural calamities, which means that a user should be able to add/
remove items in/from the cart, make payments, and do checkouts 24*7 without any down-
time, as even a few minutes of downtime may have major financial implications. When you
have many decoupled components, it is expected to have machine and network failures, so
DynamoDB was designed in such a manner that it handles failures as a normal case and
should not affect the performance and availability of the system.
DynamoDB uses a combination of the best-known techniques, which, combined together
have formed such a brilliant system. It uses a consistent hashing algorithm to achieve uni-
form data partitioning. Object versioning is done for consistency. The quorum technique is
used to maintain consistency amongst the replicas. Now, let's try to dive deep into more
such techniques and try to understand what role these techniques play in DynamoDB's sys-
tem architecture.
Search WWH ::




Custom Search