Всем привет. Подскажите, плиз, как правильно сделать? Есть консьюмер, который читает

топик и на основе пришедших данных делает расчет и отдает результат ниже. Допустим, этот констюмер «падает» по какой-то причине и рестартует автоматически. Теперь консьюмеру надо с нулевого оффсета прочитать весь топик до момента где он «упал» и заново сделать расчеты.

Учитывая реалтайм событий, делать расчеты с нулевого оффсета как-то не хочется. Смотрю в сторону compacted topic’ов. Но, не могу понять, как сказать консьюмеру, что для начала надо прочитать компактед топик. Или это решается простым обработчиком ошибок? Типа, нет компактед, читаем с нуля, в противном случае компактед и далее реалтайм.

Подскажите, как правильно делать, плиз.

результат вычислений хранить в бд

в чем преимущество перед compacted topic?

O(1) на чтение, а в компакшоне O(n) если поверх него кэш (или индекс) не намотать, а если намотать, то надо будет заморачиваться на поддержания целостности этого кэша (или индекса)🤪 Я такое делал, но это больно)

но, в таком случае мне придется поверх всего этого еще и накатывать кастомный retention policy, ибо данные "протухают" через определенное время. По большому счету, чтение из compacted topic происходит только один раз при "подъеме" контенера, поэтому, O(n) тут, думаю, не сильно влияет. Но, это опять же, мое сугубо личное мнение.

так компакшен же ретеншон полиси, на топике данные актуальные получаются, если их по порядку читать и если они шардированы в партиции по ключу. Тогда при чтении свежие значения по ключу затрут старые, если ретеншен не успел удалить устаревшие дубли. я оставлял поток с отдельным консьюмером, чтобы он обновления топика сразу писал в инмемори key-value, событие на удаление записи тоже приходит

я имел ввиду, что случае с базой данных мне надо будет заморачиваться с кастомным retention policy. Как пример моего флоу - это спортивные соревнования типа какого-нибудь футбола, когда каждые последующие расчеты статистики игры основаны на предыдущих расчетах.

Аааа, tarantool крутая DB для агрегирования и хитрых ретеншенов, но там надо немножко кодить на lua даже сам этот retention)

я в AWS все кручу и не особо хочется поднимать дополнительные provisioned инстансы для чего-то, что не будет использоваться 24х7 ;)

Интересно) Тогда и правда инмемори стейт с персистентом в кафкином компакшене - вполне себе вариант для рассмотрения))

Можно, конечно заморочиться с DynamoDB, в которой есть ttl аттрибут, но это уже история для другого чатика )) Спасибо за идею с db