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?