Querying saga state is complex and might lead to stale readers

[kbaley]

This issue was transferred from a private repository

In order to query saga state, users often use messages or other techniques in the CQRS space crafted specifically for that purpose because there is no direct access to the saga state. This not only increases complexity, it also may lead to query interpretation errors because of data staleness.

For example users are implementing some DDD patterns, e.g. the Aggregate pattern and the Process Manager one, using sagas. Aggregates and Process Managers can be seen as state machines, and sagas can be used to implement a state machine.

The side effect of using sagas in such scenarios is that there is no way to read the saga state outside the saga itself, and the only way to access saga state is through messages. This leads users to embrace eventually consistent in building a read model using events/messages published by sagas. Approach that has the following drawbacks:

• brings eventual consistency within the service boundaries
• might require even more complexity to introduce message ordering on top of non-ordered message queues

We should:

• Discuss the implications of allowing users to query the saga state (e.g. changing the saga state schema will be more complex)
• Identify what type of queries we want to start with, e.g.:
  • get-by-saga-id
  • get-by-correlation-id
• Should any kind of range query be supported (e.g. all saga states where order status is shipped)?