Consider using a listeners pool
massenz opened this issue · comments
Currently, even if running in coroutines and using channels to distribute the workload, the entire application is (essentially) single-threaded, as we only start one coroutine per task (listener, pub/sub, etc.)
We should explore the possibility of running the workers concurrently - however, this opens up the possibility of race conditions for events which, even if arriving in order from SQS, may become out-of-order (and cause unwanted issues, with transitions being deemed invalid, incorrectly).
It is non-obvious how to "single-thread" per FSM, while keeping independent event stream running concurrently.
See also #58