почитай статью хотя бы...

да лень, мне это не интересно) ради простого ответа на простой вопрос читать целую статью?

Яндекс.Касса => Ю kassa
Яндекс.Деньги => Ю money

Дурацкий брендинг, раньше лучше было. И запоминалось супер легко.

ну да, а сейчас похоже на люто подозрительный сервис

+

Это точно колизия при генерации нового значения, а не попытка повторого инсерта в базу?

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

Правда они на стековерфлоу были))

случился 1 случай на 10 в 64 степени.

а, уже было..

тот самый исторический случай. надо запомнить этот момент и внести в аналы истории.

Стремится к нулю и ноль - это разные вероятности.

В целом ничто не мешает такие случаи отлавливать и править в ручном режиме, благо они очень редки. Но в то же время если вероятность такой херни не равна нолю, то необходимо это учитывать

ретраи достаточно сделать

А если команда с уже сгенерированным ууид идёт, как ретраи поможет?

не  везде нужно сувать авто ретраи

и логировать, чтобы понимать, насколько это жизненный кейс. что-то подсказывает, что такие случаи будут 1-2 за всю историю, либо не будет вообще

ну обернуть инсерт в трай кетч, и если исключение- дубль - то генерить еще один ууид... но тут да, возможно ууид прилетает извне, и ничего не поделаешь с этим. тогда просто кидать исключение наружу / вообще не обрабатывать

Ребят, такой вопрос созрел: Кто как решает проблему отставания слейвов? Понятно, что на какое-то небольшое время они будут отставать. Вот например, клиентское приложение присылает нам свой часовой пояс и мы должны его сохранить в базу с привязкой к пользователю, идентификатор пользователя уникален в таблице. Т.е. я должен проверить существует ли запись в таблице для данного пользователя и обновить её или создать новую. Но чтение всегда со слейва.

А зачем? Ради одного двух случаев за всю историю?