4. при обновлении конфига ты пересчитываешь trigger_at

И потом trigger_at обновлять на каждом выполнении?

да

Если честно, попахивает возможными ошибками (пока не могу сказать какими, просто gut feeling).
Да и чувствовать я себя буду гораздо спокойнее, если моя логика не будет зависеть от того, сколько раз выполнилась функция)

твоя логика тут никак не зависит от того сколько раз ты выполнил функцию

делаешь select и апдейт в транзации и опционально делаешь row based lock для активации мультворкерности

это попахивает правильной архитектурой 😉

1. простое
2. корректное
3. гибкое (логика скедулинга никак не завязана на БД)
4. имеет неограниченные возможности для скейла

тебе так же придется ответить на некоторые вопросы типа:

- что если новый trigger_at меньше now()?

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

Проблема заключается в том, что выполнение функции будет зависит от предыдущего результата.
А что если у меня в 23:59:59 (или какой-нибудь другой супер редкий кейс) triggered_at посчитался неправильно?
Это значит что и следующие значения будут неправильными. Это может стать охренительным снежным комом, ведь помните историю с американской ракетной установкой, когда там часы сдвиг давали, что они потом попасть ракетой никуда не могли?)

нет, это просто делает для тебя очевидным, что скедулинг алгоритм должен быть идемпонтентым и иметь интерфейс: get-trigger-at(config, now)

как именно этого добиться решаешь ты. например точкой отсчета брать начало юникс эпохи

возможными ошибками попахивает попытка замапить скедулинг алгоритм на реляционную алгебру

или использование кварца, который на смом деле делает РОВНО то же самое. пихает в БД triggers и высчитывает следующее время его активации (я тут не на 100 процентов уверен, но на 90). только добавляет тебе парочку лишних и текущих (от слова течь) слоев абстракции

Реляционная алгебра здесь не при чем)
Мне нужна функция вида
getUsersToNotify(now: Date, allUsers: [User]) -> [User]

Шедулинг сам по себе и база (способ хранения данных) это второстепенно

так, как предлагает тебе Андрей, ты и получаешь

Его решение делает нежелательный сайд эффект

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

Tim Plotnikov, [25. Feb 2020 at 16:07:38]:
...А ещё такой момент, как обыграть кейс, когда чувак например ставит step = 2 и у него получается, что он должен получать нотификации в 10 в 12 в 14 etc?

типа HOUR(now) % step == 0 должно сработать?

вот это вот все