В рамках задачи по обработке XBRL-таксономий возникло требование: если таксономия удалена до обработки событий расчёта кэша, эти события не должны приводить к созданию данных для уже неактуальной сущности.

На первый взгляд кажется, что достаточно найти соответствующие сообщения и удалить их из Kafka topic. Но Kafka хранит данные как commit log, поэтому точечное удаление сообщений по версии таксономии или другому бизнес-признаку оказывается небезопасным.

В статье рассмотрим, почему прямое удаление сообщений не подошло, какие варианты были рассмотрены и как в итоге был применён комбинированный подход: стабильный Kafka key, tombstone-сообщения, compact/delete policy и проверка состояния таксономии на стороне consumer.

Оптимизация обработки больших отчетов в .NET Core: от памяти к потокам

Отчёты росли, память заканчивалась. Пришлось отказаться от словарей в пользу потоковой сериализации JSON. Делюсь, как реализовал запись отчёта «на лету» и заставил.NET работать с гигабайтами данных без OutOfMemory.