| Hey guys, I'm a fellow developer of distributed systems here. First of all I think what you are doing is great. My question is what's the point of clocks at all? The current time is a very subjective matter and I'm sure you know this, the only real time is at the point when the cluster receives the request to commit. Anything else should be considered hearsay. Specifically the time source of any client is totally meaningless since as you say further in the discussion that client machine times can be off by huge margins. If you accept that then one has to accept the fact that individual machines within the cluster itself are prone to drift too, although one can attempt to correct for that I appreciate. Wouldn't you think though that what is more important is that the order is more based on the bucketed time of arrival (with respect to the cluster). I don't see how given network delays anyone can be totally sure A is prior to B, atomic clocks or not. What is important is first to commit. [edit] Yes would love to talk privately about this topic @irfansharif |
You throw three more observers in and how do you make sure that all of them observe the requests arriving in the same order? Not even the hardware can guarantee that packets arrive at 4 places in the same order, even if the hardware is arranged in a symmetrical fashion (which takes half the fun out of a clustered solution).