I am practicing setting up a system using microservices and architect this system by designing each microservice as losely coupled and autonomous as possible. The application that I am setting up must make it possible to manage a video rental system. For this I have the following micro-services each with its own bounded context :
Video catalog: service used to manage the list of videos that can be rented.
User: manage user data (their address, their payment preference): I also store the date of the last rental carried out.
Online account: allows you to manage an account (login and password) identifying the user when he wishes to see the list of his rentals, to unsubscribe.
Rentals: allows you to manage a user's list of rentals.
Subscription: manages the subscription of a user and carries out the debit on the account of this one according to his method of payment.
One of the business rules that I have set for myself is this:
- In order not to have a constantly growing user base: a user and all his data are purged after 3 months of inactivity (no new rentals) if:
- he has no current rental
- he has no outstanding payments on his subscription which have not yet been settled
This rule uses several micro-services, so I tried to manage this from the user micro-service: I created a service there that runs in the background every day:
- for all users whose last rental date is more than 3 months: I check with the rental service that there are no others recorded since that date. I check with the subscription micro-service that there is no unpaid Classes. then if there was no activity or pending payment, I ask the micro-services for rentals, subscription, online account to mark user for deletion (soft delete) the user and his data from this date + a period specific to each micro-service will be physically deleted. It is always possible to cancel the soft delete independently on each micro-service if necessary.
What do you think of this design? For me it allows to keep autonomy in each micro-services.
The other alternative that I think would be to try to keep at the user service level: the date of the last rental completed, the date of the last rental in progress, and the date of the last unpaid debt. this would allow me to manage all my deletion in my user micro-service and to issue only 2 events:
- User marked for deletion due to inactivity
- User deleted after a certain period of time after the first event
On the other hand, these will have to emit events:
- at the start of a rental
- at the end of a rental
- when there is an unpaid
- when the unpaid debt is settled and that I keep a history of all these events the history of unpaid bills and rentals at the user micro-service level: it may not be a responsibility to track these histories, right?
I think you're on the right track. Deleting the inactive/invalid users can be considered as the responsibility of a specific service, which acts as an orchestrator.
One possible approach could also be to store the user id along with their last action date in a min-heap, sorted by date. Each time there's an event on the whole system (eg. rental, profile update, whatever), this microservice will update the local data and refresh the heap status. At this point, your "purging" task should just loop over the heap from the top, extracting nodes ( -> user ids to delete) till it doesn't hit a valid date.
In this example I'm using just the date, but I guess you can expand to other custom rules as well.