In some cases where the index is large, it can take a relatively long time to add or remove a tag (or interact with any real-time field, for that matter). The primary bottleneck is waiting for the commit to take place. Implementing an optimistic update could mask this bottleneck from the end user.
Ideally there would be some sort of queuing service on the back end that would handle retries, etc. if anything goes wrong. But even without that, optimistic updates still make sense because the only drawback that it introduces that I can think of (the addition/removal of a tag failing and the user not seeing) still exists with the current implementation of updating real time fields (if the user adds/removes a tag then quickly does a new search or leaves the page before the update completes).
Optimistic updates also help alleviate users getting impatient and clicking add/remove several times consecutively, which potentially result in unnecessary commits.
In some cases where the index is large, it can take a relatively long time to add or remove a tag (or interact with any real-time field, for that matter). The primary bottleneck is waiting for the commit to take place. Implementing an optimistic update could mask this bottleneck from the end user.
Ideally there would be some sort of queuing service on the back end that would handle retries, etc. if anything goes wrong. But even without that, optimistic updates still make sense because the only drawback that it introduces that I can think of (the addition/removal of a tag failing and the user not seeing) still exists with the current implementation of updating real time fields (if the user adds/removes a tag then quickly does a new search or leaves the page before the update completes).
Optimistic updates also help alleviate users getting impatient and clicking add/remove several times consecutively, which potentially result in unnecessary commits.