Recently, we encountered a situation using ATS where a service was performing a PUT with an if-match header after doing a get on a resource. Needless to say the service was encountering issues under heavy read-write load due to the fact that there is upwards of 5-10 seconds propagation delay between a PUT invalidating a cached resource at one node and the other nodes being aware of the invalidation. Consequently, if a subsequent get/modify/put was called sometimes it worked and sometimes it didn't due to the fact that depending on which node in the cluster the GET was performed on the data was either stale or it was not stale.
The work around of course was that the service was modified to use the Cache-control: no-cache header to always go to the origin service during the read/modify/write operation. However, it would be nice if there were a way to cause the response on the PUT to be delayed until the propagation of the update through the cluster was complete. Is this possible or are there constraints in play which would render such a thing infeasible?
