Today we quickly review the NoSQL design. These involve Key Value store, run on a large number of commodity machines with data partitioned and replicated between machines. This kind of system relaxes the data consistency requirement due to CAP theorem.  The infrastructure comprises of a large number of cheap, commodity nodes in a network. Each node may have the same set of software configuration but different hardware configurations. Within each node, there may be a variable number of virtual nodes. Data is partitioned based on consistent hashing. We recall that this is a way to distribute the hashtable across many virtual nodes each of which picks it set of cache objects based on replicas of different cachepoints. Cachepoints are arranged along the circle depicting the key range and cache objects corresponding to the range. Virtual nodes can join and leave the network without impacting the operation of the ring. When a new node joins the network, the joining node announces its presence and its id with broadcast. All the neighbor adjust the change of key ownership. The joining node starts to bulk copy the data from its neighbours. Other nodes receive the membership changes asynchronously. If a node does not have membership view updated yet, it will still find the right destination based on other neighbors of the joining nodes.  However, the new node may still be in the process of downloading the data and not ready to serve yet. For this case, a vector clock is used to determine whether the new node is ready to serve the request.  When an existing node leaves the network, it may not respond to the gossip protocol so the neighbours become aware. The neighbors will update the membership changes and copy data asynchronously.  Generally the crashes happen on the physical nodes so a number of virtual nodes are affected.
With multiple copies of data, we need consistency models. These include strict consistency, read your write consistency, session consistency, monotonic read consistency and eventual consistency. The strict consistency model provides semantics as if there is only one copy of data.  The read your write consistency model lets the client to see their updates immediately even on switching servers but not the updates are made by other clients. The session consistency provides read-write consistency for the client within the same session scope. The monotonic read consistency provides the time monotonicity guarantee that the client will only see more updated version of data in subsequent requests. The eventual consistency model allows the client to see an inconsistent view of an update in progress and is useful for concurrent access.  The client will need to wait for same time if he needs to see his previous update. The choice of consistency model determines how the client request is dispatched to a replica and how the replicas propagate and apply the updates.

#codingexercise
Node getLCA( node root, int n1, int n2)
{
If (root == null) return null;
If (root.data == n1 || root.data == n2) return root;
Int left = getLCA(root.left, n1, n2);
Int right = getLCA(root.right, n1, n2);
If (left && right) return root;
If (left) return left;
If (right)return right;
Return null;
}

Find the maximum product of the elements of a subarray with a given minimum size 
we sort the elements from left to right in an increasing manner.
Starting with a product of 1, we take multipliers from left and right in a greedy manner
If the multipliers are negative, we take two at a time.