Deletion of Events from Kafka Topics By setting the tombstones.on.delete to false , no deletion markers ("tombstones") will be emitted by the connector when an event record gets deleted from the outbox table. That makes sense, as the deletion from the outbox table shouldn’t affect the retention of events in the corresponding Kafka topics. Instead, a specific retention time for the event topics may be configured in Kafka, e.g. to retain all purchase order events for 30 days. Alternatively, one could work with compacted topics. This would require some changes to the design of events in the outbox table: they must describe the entire aggregate; so for instance also an event representing the cancelation of a single order line should describe the complete current state of the containing purchase order; that way consumers will be able to obtain the entire state of the purchase order also when only seeing the last event pertaining to a given order, after log compaction ran.

they must have one more boolean attribute indicating whether a particular event represents the deletion of the event’s aggregate root. Such an event (e.g. of type OrderDeleted ) could then be used by the event routing SMT described in the next section to produce a deletion marker for that aggregate root. Log compaction would then remove all events pertaining to the given purchase order when its OrderDeleted event has been written to the topic. Naturally, when deleting events, the event stream will not be re-playable from its very beginning any longer. Depending on the specific business requirements, it might be sufficient to just keep the final state of a given purchase order, customer etc. This could be achieved using compacted topics and a sufficiently value for the topic’s delete.retention.ms setting. Another option could be to move historic events to some sort of cold storage (e.g. an Amazon S3 bucket), from where they can be retrieved if needed, followed by reading the latest events from the Kafka topics. Which approach to follow depends on the specific requirements, expected amount of data and expertise in the team developing and operating the solution.