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

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

Да, ограничение должно быть на стороне хранилища.

<зачеркнуто>Какие из трех вышеуказанных: тип таймаута, айди объекта, дата/время?</зачеркнуто>

А, я понял, о чем ты. Не совсем понял только, как это может быть реализовано.

Можно разделить стадию на две.
1. Формирование условных темплейтов. Реляционное хранилище содержит готовый набор темплейтов для каждого пользователя (или группы), имеющих весь критичный набор данных. Покупка бонуса формирует новый темплейт.
2. Выбор из хранилища (в зависимости события в игре) темплейта и запись его уже в key/value хранилище (вместе с временем жизни). Никакой модификации - берем готовый объект из одного места, кладем в другое. Постгресс и редис, например.

Раз тут упомянули постгрес, то просто табличка (user_id, type_id, datetime), где первые два поля - форейн кеи на соответствующие справочники (защита от дурака) + индекс на (user_id, type_id)

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

Так. Допустим, мы это сделали. А куда девать "тип таймаута"?

Нам же тоже надо его где-то хранить/задавать.

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

Или может темплейты - это фича постгреса, о которой я не знаю? (знаю его довольно поверхностно, если честно).

ну так type_id же он и есть

А, точно. Тогда другой вопрос: что, если объект у нас не юзер, а... корабль, например?

А давайте вы задачу сформулируете с самого начала полно :)

> Начал заправлять корабль - жди пока заправится или заплати за уменьшение времени заправки.

Это было в изначальном задании.

Не, "темплейт" - просто слово, обозначающее абстрактную заготовку, не имел ввиду конкретной реализации. Я скорее про то, что за рамками хралилища (внутри, мы договорились, криворуких программистов нету) у нас нет доступа к функции прямой модификации данных (нельзя, скажем, сделать произвольный SQL-запрос). Есть доступ только к множеству иммутабельных объектов, из которого мы можем выбрать и поместить выбранное в другое место. Проще говоря, уровень абстракции над хранилищем

Такое решается в общем виде при помощи типов объектов, т.е. табличка будет на 1 колонку больше
content_type_id, object_id, type_id... и т.д.

тип объекта указывает на имя сущности БД