Есть ли срок жизни у сообщений в Kafka?
Что проверяют
Понимаете ли вы, что Kafka это журнал, а не очередь: сообщение не удаляется после чтения, а живёт по правилам топика. Следом обычно спрашивают, что будет с консьюмером, который отстал дольше срока хранения.
Как отвечать
Персонального TTL у сообщения в Kafka нет, срок жизни задаётся на уровне топика политикой cleanup.policy:
delete(по умолчанию): данные удаляются по времени или объёму. На топике этоretention.ms, по умолчанию 7 дней (на брокере то же задаётlog.retention.hours=168), иretention.bytes, по умолчанию без ограничения. Причёмretention.bytesсчитается на партицию, а не на весь топик;compact: для каждого ключа остаётся последнее значение, а запись сnullвместо значения (tombstone) удаляет ключ послеdelete.retention.ms, по умолчанию через сутки;compact,delete: оба механизма сразу, например для состояния, которое не нужно хранить вечно.
Удаление идёт не по сообщениям, а по сегментам. Сегмент удаляется целиком, только когда самое новое сообщение в нём старше срока, а сегмент закрывается по segment.bytes (1 ГБ) или segment.ms (по умолчанию тоже 7 дней). На топике с небольшим потоком первое сообщение сегмента проживёт заметно дольше недели, поэтому retention.ms это нижняя граница, а не точное время удаления.
В Java-проекте срок задают при создании топика через AdminClient или в Spring Kafka: TopicBuilder.name("orders").config(TopicConfig.RETENTION_MS_CONFIG, "86400000"). Если бизнесу нужен TTL отдельного события, его делают в консьюмере: кладут срок в заголовок и пропускают просроченное.
Где спотыкаются
Думают, что прочитанное сообщение удаляется или что офсеты консьюмеров продлевают хранение. Не продлевают: отставший консьюмер упрётся в удалённый офсет и при auto.offset.reset=latest молча перескочит в конец, потеряв данные.
Считают retention.ms точным временем удаления и строят на этом логику, например удаление персональных данных «ровно через сутки».
Путают компактизацию с удалением по времени и ждут, что компактный топик сам очистится через неделю.