I'd like to ask for some help in understanding how event-sourcing systems are used when it comes to web applications and POST requests. I understand how events are stored and the event-driven architecture of eventual consistency. I understand CQRS etc, but I cannot imagine how an event store mechanism handles something like a HTML POST request when the web application in the browser has to return the changed state on the following page we're redirected to, meaning:
I fill in a HTML form on a page to update some resource.
I press submit to POST the data to a web application.
An event is created with the data to update and the resource ID.
The event is raised and will be saved in the event store eventually.
The browser takes me to a different page in the web application.
I issue a query request to retrieve the updated resource (through replaying events) because I want to present the user with the latest state of the resource.
The query does not return the latest state because the eventual consistency hasn't taken place yet and the system still needs few milliseconds to update the event store.
I see the update never took place. The resource still looks the same.
The event store has saved the resource and now I can refresh the browser and see that the update has actually taken place.
What I am missing, please? It seems that there's something really simple here, but I cannot see how a web application can work with event sourcing. Are we relying on the event-sourcing being faster than the web application and assuming that the data will always be consistent before the user hits the next page? Wouldn't that be a bit risky during heavy system use?