эм… здесь как-бы про ситуацию, когда UI отправителя отображает успех, которого ещё не произошло

а у вас сообщение уже разослалось некоторым из адресатов, это совершенно не про optimistic update, это про inconsistent update 😂

у вас каждое сообщение не попадает в бд?

где там написано про отправителя слово?

как это всё поможет, если сообщение физически больше не существует поскольку оно пропало при неуспешной записи в бд? 🙃

Зачем вы кидаете в меня SO-скриншотом?
Я и без этого прекрасно знаю, что такое optimistic UI.

И optimistic UI не имеет отношения к другим клиентам, в отличие оттого, что вы говорите.
Optimistic UI — это когда я отправил сообщение, и оно сразу же отобразилось у меня на клиенте.
Потом если оно записалось в базу, то оно отправилось всем остальным клиентам и отобразилось у них, а если не записалось, то не отправилось всем остальным клиентам, а у меня отобразилось с ошибкой (или удалилось, если UX не важен)

почему optimistic UI не имеет отношения к другим клиентам?) опять оно комуто “должно”)

Ну потому что не имеет.
Потому что optimistic UI — это про UX, а UX — это про мою работу с моим клиентом, а не про то, как у кото-то там.

А то что вы как-то по-своему это толкуете, это, конечно, странно, но ок — толкуйте.

там про UI

если внимательно читать то суть ясна: наш UI предполагает, что side-эффект на сервере прошёл успешно.

в случае мессенджера optimistic update выглядит так:
1. я послал сообщение
2. оно сразу отобразилось в моём чате как отосланное (optimistic update)
3. сервер пыхтел пыхтел да ошибку отдал
4. UI пометило сообщение флагом “невозможно было отправить это сообщение, повторим?”

причём заметьте, кроме нас это сообщение никто ещё не видел! И это очень важно!

то что описываете вы, к optimistic update не имеет отношения, это называется inconsistent update
т.е. мы не только отобразили у нас в UI сообщение но и уже отослали его некоторым из получателей. Те кто были в сети - получили его, а те кто не был - пока ещё нет.
Следственно, если UI наша синхронизируется из бд то получится так, что некоторые адресаты сообщение увидят, а те кто не был онлайн и синхронят из бд - не увидят. Да и сами мы после очистки кэша больше не восстановим сообщение, ибо его нет в бд

^ this

Другие клиенты не должны получать какие-то сообщения, работать с сообщениями, которые не удалось записать/отправить. Это же логично)

Ну вот и мне не понятно, почему это нужно объяснять

я называю это eventualy consistent update))

к eventual consistency это не имеет никакого отношения. Eventual consistency = согласованность будет, но позже

а тут согласованности не будет никогда, сообщение пропало бесследно

Не хотел бы я пользоваться вашим мессенджером или не дай боже платёжным шлюзом

я зделаю retry и оно пройдет в базу, все клиенты увидели сообщение все довольны не ждут пол часа, не пройдет - удалю с клиентов no preblem (раз на милион никто не заметит)

Оплатил заказ, приехал курьер, протягивает пиццу и такой, "стоп. в БД не записалось. отдай пиццу обратно!"

Ну чё ты начинаешь?
раз на милион никто не заметит

Вы же не знаете как оно там используется и для чего, зачем додумывать и натягивать на свой придуманный кейс?

- ну вы ретрай сделайте(

сначала это чат потом заказ, какие ваши кйсы мне еще защитить?)