А зачем джобы на каждого юзера?
В момент списания смотреть у кого галочка стоит и у тех списывать, пусть щёлкают сколько угодно

ведите аудит того, что и кто нажимал

допустим у нас в эту минуту продлеваются 834 юзера. так совпало.
на 2 юзере произошел сбой (не важно почему, допустим база "моргнула")
первый юзер обновился, 833 юзера не обновились. и не обновятся уже

Ну это детали реализации

Ставить на всех юзеров джобы списания, и всё
Если кто-то снимет галку после, то уже не важно, на момент списания галка была

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

Не понимаю задачи
Если нужен шедулер с секундной точностью, то есть как минимум слип, не интересовался как правильно

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

да и слипы явно дурно пахнут...

Всё ещё не понимаю задачи

вобщем вашу позицию я понял, спасибо за мнение)

Как идея, очередь с переносом двоба каждый раз пока не достигается необходимая дата-время

Но такой варик не прокатит с многомиллионной базой

Если развивать эту идею, то можно зачанкать на пользователей сгруппированных по дате обновы

ну давайте на пальцах, из интереса.
1) есть произвольная группа пользователей подписанная на что то.
раз в единицу времени, для продления доступа к "что то" у пользователя должны списываться средства.
период подписки допустим от недели до месяца.

2) нужно "с точностью до +/- секунды" списывать средства у юзера для продления доступа к "что то". пример. если подписка заканчивается 2021-07-12 14:35:27 то списание должно произойти в 2021-07-12 14:35:{27-29}

3) пользователи подписываются в разное время, на разный период. на каких то "что то" может быть 1 юзер которого нужно раз в месяц продлевать а на каких то 10к размазанных по неделе, причем 7к подписались в течении одной и той же минуты.

так понятнее?

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

А, понял, событие не фиксированное

так точно

Ну тогда просто вызывать джобу по окончанию действия подписки

И типа да, надо будет чекать в базе дату и статус, понял проблему