Designing frontend experience to support backend async CQRS operations

Question

I'm developing a microservice with CQRS and Event Sourcing. When an event is saved to the event store, the service currently also saves the updated aggregate root as a JSON object in a separate table. So far I have separated the write model from the read model (though not in separate data stores).

I want to take this a step further. I want to have a microservice for the write model, and another one for the read model, for scalability concerns. Each service with their own database. I want to use messaging to maintain eventual consistency between the write and read model.

I'm concerned with how this approach would affect the user experience in a frontend app for this backend.

Say that a user creates a post. The write service returns ok, and (by design) the user then is instantly redirected to the page displaying the newly created post and its contents.

However, due to the async nature of messaging, the read model may not be consistent with the write transaction, and I risk a scenario where the read service does not yet contain the newly created post at the time where the frontend attempts to call it.

What is the conventional / industry standard way of handling a scenario like this?

Answer 1

Basically, you wait until you can read the data back before doing the redirect. "Eventual" is an unfortunate word to describe the consistency model, because it connotes a long wait. The vast majority of the time, you can measure the time it is inconsistent in milliseconds. If your latency is longer than that, either something is seriously wrong in your cluster, or you have intentionally designed it that way to take advantage of batching or spot pricing, or because of requirements like rate limiting to an upstream service.