As Technologies landscape is elevating day by day, Solution Architects often have two data persistence model to choose when it comes to data consistency in a distributed systems, They can either choose :-
- Strong consistency
- Eventual consistency
Architects needs to judicially choose which data consistency model fits their product requirement. The most common way to achieve Strong consistency is via synchronous data replication in distributed system. Again a real product will have lot of microservices and there are two most common ways in which microservices interacts :-
- Real time communication (immediate response is expected and is acted upon)
- Fire and forget message ( no response is expected and system is expected to behave as per design)
Note : Images are simplified for conceptualization, real communication will be much more complex for a distributed system.
Below figure illustrate the real time communication between services and achieving strong consistency, where response is shown to user and product State is changed based on response.
Fig : Microservice Architecture for synchronous microservice
Similarly same can be achieved by Asynchronous microservice model and it may bring eventual consistency
Fig : Microservice Architecture for asynchronous microservice or decoupled architecture
This design looks more apt, because it brings decoupling and performance efficiency. System is more resilient by following this model
At first glace, second model seems fit and provides more value. Issue comes when we connect the Response to Product UX. With Privacy and GDPR in helm, a product response should be transparent to user. Lets examine the scenario with an example.
As an EU User (GDPS compliant state), I want to delete my account.
The scenario will include :-
- Delete all user transactions
- Delete all logs ( except which is needed by legal)
- Delete all Audit Logs
- Delete user’s domain transactions
- Delete account.
This is a fine architecture as deleting user accounts involves all its lifetime interactions with product which can not be handled in real-time.
The issue with this solution is it does not propagate the actual response of user action. What user meant was , “I want to delete my account and I please let me know the actual status of what happened.” While the system revert user the immediate result of some basic operations not the actual status of whether his account was deleted or was there any issue while deleting records.
In my view, Async model is apt architecture for this problem, deletion of user’s account can not be in real-time. This problem should be fixed with product UX
- Introduce a notification icon (reference : Azure portal Notifications)
This should provide any progress update. ( needs technical backing services as well). Step by step notification can be shown to user e.g. “Audit deletion have been completed” and next response. In this approach need to give thoughts on “how to handle user even everything is completed? should user be navigated home page? This is complex solution and may not fit for small product.
- Inform user the true status in Email or Text/Notification ( for mobile apps)
Inform true response of action immediately and subsequent responses in email. E.G. “We have started processing your request to delete your account, and will notify you in email when it is completed.” Subsequently inform the True response to user when user deletion is completed or failed by email (If email address also needs to be deleted, handle it gracefully)
While Architecting product we sometime tends to overlook UX aspect of it and with Privacy and GDPR in helm, we need to consider how system should behave for User interactions and is architecture capable of handling those and responding to user.