We have put in place an account service management : its reponsability is to let a user register is account, confirm his email, etc...
We have put also in place a process layer that is reponsible to notify the user when his account is altered.
The notifications are done by a notification service that is decoupled from our account service and that notify the user based on an event mechanism. Here is an overview of the principle :
As a new requirement, our customer wants us now to send , for any notification, a reminder every 2 hours to the user. For example if the account is not yet confirmed , we will send the user a notification by email askin him to confirm his account 2 hours later... The team in charger of the UserNotification service, think that it's not their responsability to handle this because they have a stateless process and do not know about the account status for example. So they ask that the account management service should raise an event "AccountStillNotConfirmed" to ask for the notification every two hours :
The alternative is to make the usernotification statefull, or at less make it asks the account service for the list of "not yet confirm account" every two hours and send a notification if needed. The event "AccountStillNotConfirmed" seems odd to me. I am in search of the most clean way to tackle this problem.
which architecture would be preferable for you and why ? Is there another alternative way to staisfy our customer need?