You are currently viewing Eventual Consistency & an user interface

Eventual Consistency & an user interface

“Fake it, until you make it”


If you live in a world of systems designed with a Microservices or a CQRS architecture, you probably heard of the term “Eventual Consistency”. It is related to the delay between an asynchronous action and the state of the system.

For example, when an user updates an address in a web app, first an action/command is asynchronously send to a server to update the address. After that, the action/command will be processed asynchronously in x time. There will be a delay before there is an actual update in the database.

So you think, what is the problem?

The problem or challenge you have is the asynchronously behaviour, the delay and the fast response of your user’s UI.

In the example above we have a web app, which is blazing fast. 😉 After sending the command to the server asynchronously, the job of the web app is done en will return with a response to the user.

The command will be picked up eventually(!) and after processing, the address is updated. The database is consistent(!) again.

But, before processing the command, the web app is already returning the address page to the user. This address page shows the old address in the database (stale), because the command has not been processed yet.

The user will definitely and for sure be confused. (Remember, most users live in a digital world where all things seems consistent all the time)

What is Eventual Consistency in plain english to a business user?

Before I show you a few option how to handle the user experience, let me tell you an analogous example which you can use to a business user. In the non-digital world there are a lot of cases which are by nature eventually consistent.
(I love analogous (fictional) examples, if you have another one, please leave a comment below)

Give your business user a pen and paper. Tell the user he/she is in charge of creating new users in the paper-system by getting requests and generating new unique customer-id’s.
Then you start giving requests with names of users. After, each request you immediately ask the customer-id. The business won’t keep up giving you the correct customer-id’s. Eventually(!) the user generates the id’s and can give you the id’s. You both now have the same customer-id’s and are consistent(!) with each other.

A few ways to handle the user interface(UI)

As a developer, you have a few options to handle the user interface. Each option has an impact on the user experience and also your development time.

Option 1 – Do nothing, render the ui as normal with old data.

This option takes no extra effort on your development time. however the user experience is terrible to say the least. You have to explain the user how to handle eventually consistency him- or herself. I won’t recommend it.

Option 2 – Put in a delay of the response to the user. (give the server process more time)

Putting in a delay will hurt the user experience of course. Nobody wants to wait on a webpage to load.
Most of time the user gets the new consistent data and will make the right actions if needed. But, most of time is not all the time. If the server is really busy, the user still gets the old data.

Option 3 – Use a confirmation screen. (another way to delay)

Putting in a confirmation screen helps the user experience if you don’t have that many actions. (Otherwise, you have a lot of popups.)
The action/command is send before showing the confirmation screen. It takes time to click away the confirmation screen by the user, so this gives the server more time to process.
The user experience will be better, but still, the delay will help most of the time. Not all the time.

Option 4 – Fake it until you make it.

This option has a few variations. It depends on the priority of the user experience and your development time.

First of all, when the user makes an action, you “know” what’s going to be processed on the server and you can make a professional guess what the state of the UI will be.
You have to keep that state on the UI side and make this comparable with the server state.
To the user you show the UI state which will be eventually consistent with the server state.

For example, you can show a message the current data is “old” data with a timestamp. You let the user decide when to refresh the data/page. While refreshing, compare the UI state with the server state, if the server state is up-to-date, you can show the result to the user without the message.

Another way to refresh the data is to use a polling technique. You don’t ask the user to refresh the page, but in the background you check if the server data is up-to-date and will refresh the page or refresh only the required data in the screen.

And a final way is to use a publisher/subscriber technique (e.g. with SignalR). On the UI side you can subscribe to events from the server. When the action of the user is processed on the server, the server will publish an event. This event contains the up-to-date data on the server, which will be handled on the UI side.

Final thoughts

So there are many ways to handle eventually consistency. Sometimes you don’t have to handle the UI at all and make it easy for you. But most of the time there are users involved and they will expect a good or great user experience. The user experience is everywhere (e.g. websites, phones, etc.) and it is therefore important to reflect on this.

Please leave a comment below if you like this or have any questions. Thank you!

Leave a Reply