For services like session management,sales relational DB leads to limit  in scale and availability while Dynamo addresses these problems much more efficiently

Data is partitioned and replicated using consistent hashing while the consistency between replicas during updates is maintained by a quorum-like technique(Quorum protocol) and a decentralized replica synchronization protocol,

Dynamo is a completely decentralized system with minimal need for manual distribution

When to use Dynamo DB?(not restricted to!!)

 For the Application that only requires read and write operations to data item uniquely identified by a  primary key whose operations do not span across multiple data items ,Dynamo Db targets applications that need to store objects that are relatively small in size (less than 1MB)

We need to admit to that fact that the availability and consistency can not be achieved at the same time with  both contributing to 100% you have to choose one among the two

Since the Data is being replicated across many regions in various data centers when an update is performed it takes time to replicate across all the replicas .There are two choices

**)Either you make data unavailable until the complete updation across the various replicas of data is performed (Known as Strongly Consistent read)

or

**)Provide a copy of inconsistent data (with the immediate read in effect ) called as (Eventually Consistent read)

Dynamo is designed to be an eventually consistent data store with all updated reaching all replicas eventually

Dynamo Db pushes the complexity of conflicts to reads in order to ensure the writes are never rejected i.e even if the most recent update is not performed on all the replicas you can still write and keep on updating but  Dynamo will restrict you from reading the inconsistent data