Hi Robert! Thanks for your question. We would need some more details on the race-condition concerns, like an example of sequence of operations with ambiguous/erroneous/tricky behavior. Would you be able to provide it? 

Hi Anita, sure let’s see about an example. To be clear, we’re in the design phase of this service. So our question is mostly “does this raise any red flags” from your engineers. 

We have two services, one which produces and updates events on conditions in data. And another which consumes and updates events for communication to another system. In sum, a somewhat complex data-monitoring tool.

The type of sequence of operations we’re concerned about (we’re still drawing architecture for “who” owns  what part of the monitoring process) is: 

Let the event in question, E, have the following two metadata fields:

{"communicated": "foo", "status": "bar"}

Let A be the monitor which produces events, and updates the field “status” in the event. 

Let B be the consumer who listens for events, and updates the field “communicated” in the event.

Can we push updates to E from both A and B simultaneously - without regard to potential race-condition problems, or the like? 

Thanks, 

Robert

We handle race conditions by applying concurrent updates sequentially. For two concurrent updates A and B, the result would be the same as applying A and then B, or B and then A. You can safely push simultaneous updates, without regards to race conditions.