Add synchronous request reply design doc #2216
Conversation
| @@ -0,0 +1,102 @@ | |||
| # Proposal: Synchronous Request Reply | |||
|
|
|||
| Authors: Maxim Fateev (mfateev), Andrew Dawson (andrewjdawson2016) | |||
There was a problem hiding this comment.
Put the @ symbol in front of the aliases so GitHub links them
| ### Guarantee read after write consistency between signal and query | ||
|
|
||
| Currently there are situations when a query emitted after a signal sees a stale workflow state without the signal update yet delivered. This forces complications to a workflow logic as signal then query for updated state interaction pattern is not consistent. After this race condition is fixed signal then query can be used for request-reply like scenarios. The drawback of this approach is that it is not most optimal from the performance point of view as it requires at least two decisions and multiple database updates. But together with Long poll on query result changes feature it is a reasonable way to implement update and then wait for a long running update operations. | ||
|
|
There was a problem hiding this comment.
Fix a few typos in the paragraph above to make it easier to read:
Currently, there is a race condition when a query emitted after a signal sees a stale workflow state without the update from the signal. Accounting for this inconsistency complicates the workflow logic. Fixing this race condition allows the signal-then-query pattern to be used for request-reply scenarios. The drawback of this approach is suboptimal performance since it requires at least two decisions and multiple database updates. But, together with the long polling on query result changes feature, it is a reasonable way to implement update-and-wait for long-running update operations.
andrewjdawson2016
force-pushed
the
sync-rr-design-doc
branch
from
193d9f0 to
577ab55
Compare
No description provided.