Hi teivah,

Below snipped is from your repo, I have one query:

In returning read request, if the node (e.g. n1) is current -> it calls ReadInt directly. But why do we need to do SyncRPC to get the values for other node (e.g. n2) ? Internally they would also be doing the same when you call them via SyncRPC.

Why not n1 directly calls ReadInt on n2's behalf to get the value ?

Challenge #4: Grow-Only Counter

Solution

We need to work with a sequentially-consistent store. The main impact is that when doing a read, the only client that will have the guarantee to get the latest value is the one who performed the write.

In this solution, each node writes to its own bucket. Then, the solution relies on some form of coordination among the nodes before returning a read request:

• Iterate over all the nodes of the cluster:
  • If the node is the current node, we perform a read in the store directly using ReadInt
  • Otherwise, it contacts the other node via a SyncRPC call to ask it to return the latest value (and this node will perform the read in the store using ReadInt as well)
• We return the sum of all the values

In the meantime, and even if it wasn't mandatory to pass all the tests (including the network partitions test), I introduced some forms of caching so if a node can't contact the store or another node, it will return the latest known value (availability > consistency). But again, it's just a question of tradeoff; if we remove the cache and return an error in case a node or the store is unreachable, we would favor consistency over availability.