A Generalized Microservice abstract

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 :-

1. Real time communication (immediate response is expected and is acted upon)
2. 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

Problem with Async model when associated with User Interaction

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 (GDPR compliant state), I want to delete my account.

The scenario will include :-

1. Delete all user transactions
2. Delete all logs ( except needed by legal)
3. Delete all Audit Logs
4. Delete user’s domain transactions
5. ..
6. ..
7. 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 reverts user the immediate result of some basic operations and  not the actual result ( what if there is some issues while deleting audit records?)

Solution

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 by communicating actual information back to user.

• Introduce a notification icon (reference : Azure portal Notifications) 

This should provide any progress update( it needs technical backing services in backend). Step by step notification can be shown to user e.g. “Audit deletion have been completed” and then the next response. In this approach one needs to give thoughts on “how to handle user when everything is completed?” should user be navigated to home page? This is complex solution and may not fit for small products.

• 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 account, and will notify you when it is completed.” Subsequently inform the actual response to user when user deletion is completed or failed (If email address also needs to be deleted, handle it gracefully)

Takeaway

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 if architecture is capable of handling those.