What is the epoch fencing mechanism in Kafka transactions?

When a transactional producer with a given transactional.id initialises its transactions, the Transaction Coordinator bumps the producer epoch for that transactional.id, so that any previous zombie instance of the producer is fenced off (KIP-98). Requests to the coordinator and writes to partitions carry the PID and epoch, so an old zombie producer with a lower epoch is rejected, for example with INVALID_PRODUCER_EPOCH or a ProducerFencedException; the higher-epoch producer has fenced it. This solves the zombie producer problem: after a restart, or a false failure detection, the old process may still be running. The Kafka docs add that setting transactional.id makes a restarted application cause any in-flight transaction from the previous instance to abort. Brokers also reject writes that carry an older epoch. With the newer transaction protocol (KIP-890, transaction version 2) the epoch is also bumped when each transaction ends, so a delayed message from an earlier transaction cannot be added to a later one.

Expected key concepts: transactional.id, producer epoch, Transaction Coordinator, zombie producer, fenced, lower epoch, rejected, PID, in-flight transaction, abort, KIP-890