Name some of the record types the active controller appends to the metadata log and explain what each represents.

In KRaft, metadata is *event-sourced*: rather than storing the current state directly, Kafka stores an ordered log of *change events*, and current state is computed by replaying them. Each event is a strongly-typed **record** with an `apiKey` (which record type) and a `version` (so the schema can evolve compatibly). The active controller is the only writer; it appends these to the internal single-partition topic `__cluster_metadata`. **Common record types:** - **TopicRecord** — emitted when a topic is created. Carries the topic name and a globally unique topic *id* (a UUID). Topic deletion is a `RemoveTopicRecord`. - **PartitionRecord** — describes one partition: its replica assignment (which broker ids hold replicas), the current leader, the in-sync replica set (ISR), the leader epoch, and partition epoch. Emitted when a partition is first created. - **PartitionChangeRecord** — an *incremental* update so the controller doesn't re-emit a whole PartitionRecord for every small change. It records only what changed: a new leader, a shrunk/grown ISR, a reassignment step, etc. This keeps the log compact. - **RegisterBrokerRecord** — written when a broker registers with the controller. Contains the broker id, listener endpoints, features, and an *incarnation id* (a UUID that distinguishes a fresh process start from a previous one). - **BrokerRegistrationChangeRecord / FenceBrokerRecord / UnfenceBrokerRecord** — track whether a broker is *fenced* (temporarily not eligible to host leaders, e.g. because it missed heartbeats) or active. - **ConfigRecord** — a dynamic configuration change (topic-level or broker-level). - **ProducerIdsRecord, AccessControlEntryRecord, FeatureLevelRecord, ClientQuotaRecord** — producer-id block allocation, ACLs, feature-flag levels, and quotas respectively. **Why typed records matter.** Because each is versioned, Kafka can add fields or new record types across releases while old replicas still parse what they understand. Because they are ordered and appended by a single writer, every node that replays the same log prefix derives the same state — the foundation of KRaft's consistency. **Edge cases:** records are only applied after they are *committed* (a quorum majority has them); the log is periodically *snapshotted* so a new node doesn't have to replay from the beginning of time; and `PartitionChangeRecord` is favored over re-emitting `PartitionRecord` specifically to bound log growth during churn.