Immediate is nicer to reason about but quite hard these days. If you can get away with an architecture that is basically glorified LAMP with some transactional db, great, but a lot of projects are a bit more complicated than that. In architectures where you are dealing with search engines, asynchronous processing via queues, micro services, etc. you can't always wait for everything to catch up. A lot of this stuff is just fundamentally non transactional.
In my experience when building software like this with web based, and worse, mobile uis, things get quite hairy. These types of environments favor small payloads and fast requests. You don't want uis to block while a server waits for seconds to get some update through all its backend systems. At the same time you don't want to serve stale data to your users.
A good example is somebody is a user looking at a screen with search results. They 'edit' an item in some way and now they go back to the search results which are now out of date because it just takes a few seconds for updates to trickle through queues, be processed, and re-indexed in Elasticsearch. So there is a brief window where the results are inconsistent with what the user just did. That's a potential problem because it may cause the user to assume the update didn't happen.
A bad solution for this: grey out the screen and update a few seconds later and hope for the best. This creates a really bad experience because the system will be perceived as slow when in reality it is the frontend or some server side view doing a sleep to fake consistency. The better solution is to change the UX to not create this expectation of real time consistency when it is expensive to provide it and have network plumbing in place that ensures the UI is updated with fresh data when it comes available. This creates a more fluent experience and most users understand that their actions seconds ago may cause data to be updated in the UI. Use some nice animations, maybe some notification indicating success, etc. Blocking users and forcing them to wait is much worse than allowing them to continue to work but it requires UX to be aligned with reality.
This is the reason why most UI frameworks have switched from server side MVC to client side MVC with all the blocking stuff happening asynchronously. This is also why things like html 2, websockers, graphql, have become a thing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Immediate is nicer to reason about but quite hard these days. If you can get away with an architecture that is basically glorified LAMP with some transactional db, great, but a lot of projects are a bit more complicated than that. In architectures where you are dealing with search engines, asynchronous processing via queues, micro services, etc. you can't always wait for everything to catch up. A lot of this stuff is just fundamentally non transactional.
In my experience when building software like this with web based, and worse, mobile uis, things get quite hairy. These types of environments favor small payloads and fast requests. You don't want uis to block while a server waits for seconds to get some update through all its backend systems. At the same time you don't want to serve stale data to your users.
A good example is somebody is a user looking at a screen with search results. They 'edit' an item in some way and now they go back to the search results which are now out of date because it just takes a few seconds for updates to trickle through queues, be processed, and re-indexed in Elasticsearch. So there is a brief window where the results are inconsistent with what the user just did. That's a potential problem because it may cause the user to assume the update didn't happen.
A bad solution for this: grey out the screen and update a few seconds later and hope for the best. This creates a really bad experience because the system will be perceived as slow when in reality it is the frontend or some server side view doing a sleep to fake consistency. The better solution is to change the UX to not create this expectation of real time consistency when it is expensive to provide it and have network plumbing in place that ensures the UI is updated with fresh data when it comes available. This creates a more fluent experience and most users understand that their actions seconds ago may cause data to be updated in the UI. Use some nice animations, maybe some notification indicating success, etc. Blocking users and forcing them to wait is much worse than allowing them to continue to work but it requires UX to be aligned with reality.
This is the reason why most UI frameworks have switched from server side MVC to client side MVC with all the blocking stuff happening asynchronously. This is also why things like html 2, websockers, graphql, have become a thing.