I'm trying to understand and learn how to build microservice messages the best and came up with this task for myself:
- Accounts Service
- Token Service
- Email Service
When a user registers the account needs a token for the verification email. The token service will issue tokens with a life time that can expire. The registration email can only be send when a token was received. So we will have to wait for that to complete.
When the token was received, the aggregates states is updated and a command send to the Email service to send the registration email. We don't need to wait for that this is going to complete successfully but flag the account that the email was sent.
User Registration Saga
- Status: TokenPending
- Command: CreateToken -> Token Service (returns token)
- Event: TokenCreated -> Account Aggregate listens, updates itself
- Status: EmailPending
- Command: SendEmail -> Email Service (returns success or failure)
- Event: RegistrationEmailSent -> Account Aggregate listens, updates itself
- Status: Completed
When and where would I create or use the Saga object? A saga seems to be another object in my system. The example on the microservices.io shows that the saga is created before the aggregate, is this correct? So after the saga is completed I would create my new account aggregate? The Saga itself looks like an aggregate. Could it be modelled as such? See the diagram example at the end of this post, its the orchestration example from microservices.io.
Is applying the Saga pattern this way a good solution for this made up scenario? The Saga Pattern. Are there other solutions to the given scenario that might be better? If yes, why?