альтернативы какие?

Я, как бы, не про сам токен, а про то, что без блеклиста(да простят меня за такое слово) нельзя запретить вход клиенту. Ведь токен валидный до тех пор, пока не истечет. Ну и если в нем еще и роль зашита, то смена роли на лету вообще через пятую точку

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

под таким углом не смотрел, надо обдумать, спасибо большое за совет

раз все в микросервисах то почему бы не написать микросервис который хранит и рефрешит токен?

спасибо за ответ.
если честно, то мне немного звучит, как overhead поднимать еще один микросервис для такой простой задачи + смотреть, чтобы он не упал + не совсем вижу, как микросервис решит проблему (может не до конца понял вашу идею)

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

Спасибо, теперь понял о чём вы. Подумаю об этом

А у меня в связи с обсуждением тоже назрел вопрос. А как в микросервисах и кубере решают задачу распределенных примитивов(локи, лидер елекшн). Сейчас у нас монолит и отдельно поднят зукипер (там же дискавери). Вообще появляется ли такой вопрос в микросервисах? И если про leader election (заставить только один инстанс приложения выполнять отдельную логику) можно решить, просто выделив в отдельный сервис, то что делать с локами не понятно. Отдельный etcd/zookeeper/redis?

я обычно беру что-то типа https://github.com/lukas-krecan/ShedLock и использую (как бэкенд - или какой-то постгресс, или что-то еще, тут много вариантов)

известный мне подход: локи в бд. если нужно выполнять другую/немного друю логику то можно и настройку окружения передать. как бы постгрес по умолчанию а для редких вопросов синхронизации что-то поднимать отдельное вроде неэффективно

на абсолютную правильность не претендую но оно работает :D

Локи в бд может быть очень неэффективно (если модель пуллинга бд), зукипер, етсд дают модель подписки на изменение ключа

Тоже опирается на что-то типа бд, зукипер и тд. Я так понимаю это скорее аналог spring-cloud компонента лока, чем отдельное решения для синхронизации

конкретно в моем приложении локи это именно локи данных. по этому так

Локи данных в бд? Или распределенные локи в приложении?(java.concurrent.Lock)

так-то согласен что эти вещи эффективнее хотя бы потому что бд не совсем тот инструмент для разруливания синхронизации

первое

Тогда понятно, вопрос именно синхронизации блоков в коде, чтобы в этот момент не появилось несогласованных данных например (проблема атомарности проверки наличия данных)

кстати интересно было бы узнать для каких примерно задач предполагаются эти локи? распределеные транзакции?