Take a look at competing consumers.
You can make the email sending saga a consumer, and in that pattern there are persistent queues that record of wether a particular message/task was handled or not.
I use Eventstore.org built-in competing consumer functionality.
Thank you for reading!
Please, don’t use this as a general guide on good practices :-) I wrote this mostly as an observation, and it should not be taken as a general engineering guidance. In fact, I find it hard to think in terms of actuators/sensors etc.
What are the terms “subject”, “token”, “claims” and “resource” in the snippet below? Thanks.
def subject_for_token(user, _claims) do
sub = to_string(user.id)
def resource_from_claims(claims) do
id = claims["sub"]
user = Accounts.get_user(id)
What about authentication?
If a user signed into SCS A, and they get sent to system B – they will no longer be signed into the “overall” system from their point of view.
Very interesting. So it is driven by people concerns and not architectural or functionality or requirements.
What a different way to think about things!
I think I understand now. So if I’m building a system by myself, there should really be no reason for me to create two SCSs, because I am just me.