You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, running multiple SM servers behind a gateway or reverse-proxy, all connected to the same Redis cluster, could cause races and inconsistencies if events for the same FSM are processed out-of-order.
We should at least consider a leader/follower architecture, with the replicas being read-only (possibly having the primary to be event-processing only).
Alternatively, the followers could be standby only, and ready to take over in case of primary failures, but otherwise not processing any request at all.
This needs some careful considerations, and also a clear definition of use-cases and requirements.
The text was updated successfully, but these errors were encountered:
Currently, running multiple SM servers behind a gateway or reverse-proxy, all connected to the same Redis cluster, could cause races and inconsistencies if events for the same FSM are processed out-of-order.
We should at least consider a leader/follower architecture, with the replicas being read-only (possibly having the primary to be event-processing only).
Alternatively, the followers could be standby only, and ready to take over in case of primary failures, but otherwise not processing any request at all.
This needs some careful considerations, and also a clear definition of use-cases and requirements.
The text was updated successfully, but these errors were encountered: