Consistency models

Question 1

Strong consistency

Answer 1

Strong consistency gives the illusion that there is a single
database (despite the fact that the implementation is replicated
and partitioned).

Strong consistency offers linearizability.
1. A read is guaranteed to return the most recently committed
version of an item.
2. A client never sees an uncommitted or partial write.

Question 2

linearizability

Answer 2

1. A read is guaranteed to return the most recently committed
   version of an item.
2. A client never sees an uncommitted or partial write.

Question 3

Bounded Staleness

Answer 3

The database state evolves by applying all updates in a total order – all
updates outside the staleness window are applied in the same total order in
all replica.

Question 4

Updates inside the staleness window - when there is a single write region

Answer 4

• For clients in that region, updates are totally order immediately
  (equivalent to strong consistency)
• For clients in other regions, clients may miss updates inside the staleness
  window, but they will see them in order (leading to consistent prefix)

Question 5

Updates inside the staleness window - when there are multiple write regions

Answer 5

• For clients writing to a single region, clients will observe those updates
  updates in order (equivalent to consistent prefix)
• When client write to different regions, updates are applied locally but
  may be reorder later (leading to eventual consistency)

Question 6

Bounded staleness garantees

Answer 6

1. Reads observe a consistent-prefix, i.e., all updates are
   totally ordered except within the “staleness window”.
2. Monotonic read, meaning that clients observe a version
   that is later that the previously read. Why is this interesting?
3. A read might return an old value of the data item, configured
   as:
   * The number of versions (K) behind the current version that the
   read can return;
   E.g. with K = 5, the client knows that it might miss up to 5 writes.
   * The time interval (T) for which it might miss a write.
   E.g. with T = 10ms, the client knows that it might miss updates
   executed in the last 10 ms.

Question 7

How to implement bounded staleness

Answer 7

• Master region orders and propagates updates to other regions.
• A region can receive operations that propagate to the master
  region to be ordered – while the order is not established by
  the master, these updates are visible out-of-order in the local
  region.
• Read can be performed in the local region, given that the
  bounded conditions can be established locally – e.g. from the
  last message received from the master, a replica know the
  potential staleness.

Question 8

Session (Intuition)

Answer 8

The client has a session, where she sees the database evolving
as if it was a single replica. Updates from other clients/regions
are integrated in the view of the session.
Note: different clients with this consistency level may see
different database states.

Question 9

Monotonic writes

Answer 9

Writes are propagated after writes that
logically precede them.

Question 10

Write-follows-reads

Answer 10

A write is propagated always after the
read updates.

Question 11

Read your writes

Answer 11

a read always reflects the writes executed
in the session.

Question 12

Guarantees

Answer 12

Within a single client session, reads are guaranteed to
honor the consistent-prefix (assuming a single “writer”
session), monotonic reads, monotonic writes, read-yourwrites, and write-follows-reads guarantees

Clients outside of the session performing writes will see:
* Clients in the same region (either reading only or writing) will see
updates in order (leading to consistent prefix)
* Clients in other regions, with updates performed in a single region,
will see update in order (leading to Consistent prefix)
* For client writing in other regions, they may see their update being
reorder in relation to the writes of other regions (leading to Eventual
consistency)

Question 13

How to implement session

Answer 13

Client maintains version vector (token, context) with a
summary of the operations observed;
* Reads request a state that is at least as recent as the vector;
* Updates in each region are ordered and this order is
respected when applying them to other replicas).

Question 14

Consistent prefix (intuition)

Answer 14

The client sees a prefix of the updates from every region, but
might miss recent updates from different regions.

Question 15

Guarantees (Consistent prefix)

Answer 15

1. Results that are returned contain some prefix of all the
   updates, with no gaps;
2. Reads never see out-of-order writes from a region (i.e., it
   always observes updates executed in region in the same
   order).

Question 16

How to implement?

Answer 16

• Region orders updates and propagates them to the replicas;
• Reads sees the updates received by the master (in order)
  more local request.

Question 17

Eventual consistency

Answer 17

The client might see a state that reflects any subset of the
updates.
Under eventual consistency, there is no ordering guarantee for
reads. In the absence of any further writes, the replicas
eventually converge.

Question 18

Optimal solution for most applications

Answer 18

Session?

Question 19

What if stronger consistency is needed?

Answer 19

select bounded staleness. Bounded staleness is almost as good as strong
consistency if the bound is small, but reads can be processed
locally.

Question 20

What if your application requires eventual consistency?

Answer 20

it is recommended that you use consistent prefix consistency
level – provide better guarantee with similar cost.

Question 21

What if your application requires eventual consistency?

Answer 21

it is recommended that you use consistent prefix consistency
level – provide better guarantee with similar cost.

Question 22

Types of conflicts

Answer 22

Insert conflicts: These conflicts can occur when an
application simultaneously inserts two or more items with the
same unique index in two or more regions.
Replace conflicts: These conflicts can occur when an
application updates the same item simultaneously in two or
more regions.
Delete conflicts: These conflicts can occur when an
application simultaneously deletes an item in one region and
updates it in another region.

Question 23

Confit resolution policies

Answer 23

Last-Write-Wins (LWW): uses a system-defined timestamp
to select which version to keep.
Application-defined (Custom): possible to define a merge
procedure to solve conflicts. These procedures get invoked
upon detection of the write-write conflicts – the procedure
executes exactly-once.

Question 24

Durability

Answer 24

Recovery time objective (RTO) is the time until an
application recover from a disruptive event.
Recovery point objective (RPO) is the period of time for
which updates might get lost in a failure.

Question 25

Pricing

Answer 25

The cost of the throughput provisioned and the storage consumed on an hourly basis. * Not cheap if you are not using it. The request unit is based on the number and type of operations and the data transferred.