Explain how brokers consume the metadata log as an event-sourced state machine, and what guarantees this provides.

**Event sourcing recap.** In an event-sourced system you do not store the current state; you store an ordered list of *events* (changes). Current state is derived by starting from an empty state and applying every event in order — a *fold* or *reduce*. KRaft applies this to cluster metadata. **The flow.** The active controller appends records (TopicRecord, PartitionRecord, RegisterBrokerRecord, etc.) to `__cluster_metadata`. Every broker acts as a Raft *observer*: it issues `Fetch` requests against the controller quorum to pull new records. Internally, a component (historically `BrokerMetadataListener`, now organized around the `MetadataLoader` + `MetadataImage`/`MetadataDelta` types) applies each record to an immutable in-memory image. Applying records produces a new `MetadataImage`; the difference between consecutive images is a `MetadataDelta`, which *publishers* turn into actions — for instance, when a `PartitionRecord`/`PartitionChangeRecord` makes this broker the leader of a partition, the broker starts accepting produce traffic for it. **Metadata offset.** Each broker knows the *offset* of the last record it applied. This is its position in the event stream and a direct measure of how current its view is. Tools and metrics (e.g. `current-metadata-offset`) expose this; the gap between a broker's offset and the log end is its metadata *lag*. **Guarantees.** 1. *Total order*: single writer + single-partition log ⇒ one canonical event order. 2. *Determinism*: applying the same prefix yields the same state on every node — so two brokers at the same offset are byte-for-byte consistent in their metadata view. 3. *Eventual consistency*: brokers may momentarily be at different offsets, but each is a consistent snapshot of some committed prefix, and all converge as they catch up. 4. *Durability*: only *committed* records (replicated to a quorum majority) are exposed, so replayed state never reflects an uncommitted change that could be lost. **Snapshots.** Replaying from the beginning forever is impractical, so the metadata log is periodically **snapshotted**: a compacted image of state at offset N is written, and the log before N can be truncated. A starting or recovering broker loads the latest snapshot, then replays only records after it. This bounds startup time and disk use. **Edge cases.** A broker that lags badly (e.g. slow disk, GC) keeps a stale view; KRaft *fences* brokers that miss heartbeats so they don't serve as partition leaders with stale metadata. The metadata view is read-locally and lock-free because images are immutable and swapped atomically. And because this is a state machine, recovery is just 'load snapshot, replay tail' — there is no ad-hoc reconciliation logic as there was with ZooKeeper watches.