Before we open the log, we must understand the problem it solves and the older solution it replaced.

What is metadata?

Metadata simply means data about data. When you send a message to Kafka, the message itself is the data. Facts such as “this topic exists”, “it has twelve partitions”, “partition seven lives on brokers one, four and nine” and “broker four is the leader for partition seven” are metadata. Without metadata, brokers would not know where anything lives, and clients would not know whom to talk to.

Metadata changes far less often than messages, but it is far more important. A wrong message affects one consumer. A wrong piece of metadata can make two brokers both believe they are the leader of a partition, and that can corrupt data for everyone.

How the old design worked

In the original design, one broker was elected as the controller. The controller made decisions such as choosing new partition leaders when a broker died. But the permanent record of the cluster lived in ZooKeeper, a separate cluster of servers. Every broker also kept its own cached copy, and the controller pushed updates to brokers using direct remote calls.

This meant two systems to install, secure, monitor, upgrade and understand. It also meant that the truth was stored in one place (ZooKeeper) while decisions were made in another (the controller), and the two could briefly disagree.

The pain points that motivated a change

The big idea: metadata as an event log

The Kafka community proposed a change in an improvement proposal known as KIP-500. Instead of storing the cluster state in an outside database, Kafka would record every change to that state as an event in a log, and a small group of servers would agree on that log using a consensus algorithm called Raft. Brokers would no longer be told about changes by push. They would simply read the log, the same way a consumer reads a topic.

That log is the KRaft metadata log. The name KRaft is short for Kafka Raft. It is the heart of how a modern Kafka cluster knows what it is.

The metadata log stores much more than a list of topics. It is the complete description of the cluster.

Every durable fact that must survive a restart and be agreed upon by every server belongs in the metadata log. If you could freeze a cluster and write down everything a brand-new broker would need to behave correctly, that list is the metadata.

What is deliberately not in the metadata log

Your actual messages are never stored in the metadata log. Consumer group offsets are kept in an internal topic managed by the group coordinator, not here. Transaction state has its own internal topic too. The metadata log is intentionally small and focused: it holds the cluster’s structure and rules, not its traffic.

To trust the metadata log, you must first understand how a group of servers agrees on anything at all.

The agreement problem

Suppose three servers each hold a copy of the register, and a request arrives: “create topic orders”. If server A records it but B and C never hear about it, the copies disagree. If A then crashes, the change may be lost even though a client was told it succeeded. Consensus algorithms exist to prevent exactly this. They give a strict rule: a change only counts once a majority of servers have safely stored it.

The core vocabulary

Majorities and fault tolerance

The magic of a majority is that any two majorities must overlap by at least one server. That overlapping server remembers the latest decision, which is why the group never forgets committed history. The price is that you can only tolerate a minority of failures.

Why Kafka adapted Raft

Standard Raft has the leader push new entries to followers. Kafka’s version is pull-based: followers issue fetch requests to the leader, exactly like consumers and follower replicas already do elsewhere in Kafka. This let the Kafka team reuse existing code, existing network protocols and existing operational knowledge. It also made it natural for non-voting brokers to follow the same log with the same mechanism.

The metadata log looks a lot like a normal Kafka topic, with a few important twists.

A special one-partition topic

The log is stored as an internal topic named __cluster_metadata with exactly one partition. There is no need for more, because metadata changes must be strictly ordered. A single ordered stream is the simplest way to guarantee that every server replays the same changes in the same order and therefore reaches the same state.

Offsets, epochs and record batches

Every record has an offset, which is its position in the log, starting from zero and rising by one. Every batch of records is also stamped with the leader epoch under which it was written. Together, the pair of offset and epoch uniquely identifies a point in history. This pair is how servers detect and repair disagreements after a leader change.

Records are grouped into batches for efficiency, exactly as in ordinary topics. The active controller may combine several small changes into one batch, and a single client request can produce more than one record. Creating a topic with three partitions, for example, yields a record for the topic and separate records for each partition.

Where the log lives on disk

Each controller and each broker keeps its own copy of the log in a directory chosen by the metadata log directory setting. If that setting is empty, Kafka uses the first data directory. The directory contains segment files, index files and, as we will see later, snapshot files. Because losing this directory means losing a server’s local memory of the cluster, many operators place it on a dedicated, reliable disk.

Durability first

Raft’s safety depends on a server never telling the leader “I have stored this record” unless the record would survive a crash. For that reason the metadata log is written with a strong durability posture, flushing data to disk aggressively rather than trusting the operating system to do it later. This makes metadata writes a little slower than ordinary message writes, but metadata changes are rare and precious, so the trade is worth it.

A KRaft cluster is made of servers that play different roles around one shared log.

Process roles

Each Kafka process declares what it does through a role setting. A process can be a broker, a controller, or both at once. Brokers serve clients and store message data. Controllers hold the metadata log as voters and, one at a time, act as the leader that makes cluster decisions.

flowchart TB
    subgraph Q["Controller quorum - voters"]
        C1["Controller 1 - active leader"]
        C2["Controller 2 - follower"]
        C3["Controller 3 - follower"]
    end
    C2 -->|"fetch metadata log"| C1
    C3 -->|"fetch metadata log"| C1
    B1["Broker 1 - observer"] -->|"fetch metadata log"| C1
    B2["Broker 2 - observer"] -->|"fetch metadata log"| C1
    B3["Broker 3 - observer"] -->|"fetch metadata log"| C1
    B1 -->|"heartbeat"| C1
    B2 -->|"heartbeat"| C1
    B3 -->|"heartbeat"| C1
    CL["Admin client"] -->|"create topic"| C1
        

How the quorum is described

In the classic setup, an operator lists every voter, with its numeric identifier and address, in the quorum voters setting. Every controller and every broker receives the same list, so everyone knows whom to ask. In newer releases with dynamic quorums, a bootstrap list is used only to find the quorum, and the true voter set is stored inside the log itself. We cover that in detail later.

Two separate networks of conversation

It helps to keep two conversations apart in your mind. The first is the client conversation: producers and consumers talk to brokers about messages. The second is the control conversation: brokers and controllers talk about cluster state. Controllers listen on their own dedicated listener, named by the controller listener names setting, so control traffic can be secured and firewalled separately.

Every change to the cluster becomes a small, typed record. Learning the main types is like learning the verbs of the cluster’s language.

The metadata log does not store a giant picture of the cluster. It stores a story of changes. Each record says “this happened” or “this is now true”. A server that reads the story from the beginning ends up with the same picture as every other server that read the same story.

More record families you will meet

There are also records for client quotas, access control entries and their removal, SCRAM credentials, delegation tokens, producer identifier blocks, and internal housekeeping such as no-op records. A no-op record is a harmless heartbeat the leader can append so the committed point of the log keeps advancing even when nothing else is happening.

Newer releases also have transaction marker records. When a single administrative request needs to change several things atomically, such as creating a topic together with all its partitions, the controller can wrap its records between a begin marker and an end marker. Readers apply the whole group or none of it. If the leader fails halfway, an abort marker lets everyone discard the partial group.

Following one request from start to finish shows how all the pieces cooperate.

Let us trace what happens when an administrator asks the cluster to create a topic named orders with three partitions. Along the way you will see the active controller, the followers, the commit rule and the brokers each play their part.

sequenceDiagram
    participant A as Admin client
    participant L as Active controller
    participant F as Follower controllers
    participant B as Brokers
    A->>L: Create topic orders
    L->>L: Validate and plan replicas
    L->>L: Apply tentatively in memory
    F->>L: Fetch new records
    L-->>F: Topic and partition records
    F->>L: Fetch again, reporting stored offset
    L->>L: Majority stored, advance high watermark
    L-->>A: Topic created
    B->>L: Fetch committed records
    L-->>B: Topic and partition records
    B->>B: Create local partitions
        

The active controller is a carefully engineered single-threaded engine. Understanding it explains both its speed and its limits.

One thread, one queue, no locks

The controller component in KRaft processes every request as an event on a single queue, handled by a single thread. This may sound slow, but it removes an entire class of bugs. With only one thread changing the state, there are no race conditions, no locks to reason about, and every request sees a consistent world. Because each event is small and the state lives in memory, this design is very fast in practice.

Speculative execution with rollback

Here is the clever part. When the controller handles a request, it does not wait for the majority before updating its in-memory state. It applies the change immediately, so the next request can build on it. But those changes are provisional until committed. The controller keeps its state in special data structures that remember earlier versions, called timeline structures. If the leader loses its position before the change is committed, it simply rewinds its memory to the last committed point and forgets the uncommitted changes.

This lets the controller pipeline many requests without waiting for each one to be replicated. Throughput rises, while safety stays intact because no reply is sent to a client until its records are committed.

flowchart LR
    R["Client request"] --> Q["Single event queue"]
    Q --> V["Validate against in-memory state"]
    V --> G["Generate records"]
    G --> M["Apply provisionally to timeline state"]
    G --> P["Append to Raft log"]
    P --> H{"Majority stored?"}
    H -->|"yes"| C["Mark committed and reply to client"]
    H -->|"leadership lost"| X["Roll back to last committed state"]
        

Batching and linger

Appending each tiny record separately would waste disk and network effort. The controller therefore groups records that arrive close together and waits a short moment, a linger time, before handing a batch to the Raft layer. Larger batches raise throughput, and the short wait keeps latency low. Operators rarely need to tune this, but it explains why bursts of topic creation are handled gracefully.

Background duties of the controller

The quorum must always have exactly one legitimate leader. Epochs are the tool that guarantees this even during chaos.

States of a voter

At any moment a voter is in one of a few states. A follower is following a known leader. A candidate is asking others to vote for it. A leader is the winner and is serving requests. There is also an unattached state where a voter does not currently know who leads, and a resigned state for a leader that is stepping down gracefully.

How an election unfolds

Epochs as fencing tokens

Every message between voters carries the sender’s epoch. If a server receives a message with a lower epoch than it knows, it rejects it and tells the sender the newer epoch. A former leader that was merely slow, or cut off by a network problem, discovers on its first contact that time has moved on and immediately steps down. This is what prevents two servers from both acting as leader in the same epoch.

stateDiagram-v2
    [*] --> Follower
    Follower --> Candidate: leader silent, election timeout fires
    Candidate --> Leader: majority of votes received
    Candidate --> Follower: another leader found or higher epoch seen
    Candidate --> Candidate: split vote, new epoch
    Leader --> Follower: higher epoch seen
    Leader --> Resigned: graceful shutdown
    Resigned --> Follower
        

Pre-vote to prevent disruption

A known weakness of basic Raft is that a server cut off from the network keeps raising its epoch. When it rejoins, its high epoch forces the healthy leader to step down for no good reason. Newer Kafka releases address this with a pre-vote step: before raising the epoch, a would-be candidate asks whether others would grant a vote. If the leader is still healthy for them, the answer is no, and no disruption happens.

Replication is where the safety promises of Raft become concrete.

Pull-based replication in detail

Followers and observers send fetch requests to the leader. Each request says, in effect, “I have everything up to this offset, and the last record I have was written in this epoch. What comes next?” The leader replies with the next batch. Because the request contains both the offset and the epoch of the last record, the leader can instantly check whether the requester’s history matches its own.

Detecting divergence

If the requester claims a position that the leader’s log does not contain, or that was written in a different epoch, the leader responds with a hint: the last offset and epoch where the histories agree. The requester then truncates its log back to that point and resumes fetching. This is how a former leader with uncommitted records, or a follower that was offline, is brought back into line with the true history.

The high watermark

The leader tracks how far each voter has replicated. The high watermark is the highest offset that a majority of voters have stored. Everything at or below it is committed. The leader advertises the high watermark in every fetch response, so followers and brokers know which records are safe to apply.

A log that only ever grows would eventually be too large to replay. Snapshots are the solution.

The problem of an endless story

Imagine a cluster that has existed for years. Millions of records describe every topic ever created, every broker that ever joined and every setting that was ever changed. A brand-new broker replaying all of that from the beginning would take a very long time, and disks would fill with ancient history. Most of those old records have long been superseded by newer ones.

What a snapshot is

A snapshot is a file containing the complete state of the cluster at one exact point in the log, written as a compact series of the same kinds of records. It is labeled with the end offset and the epoch that it represents, so its meaning is unambiguous. It begins with a header record and finishes with a footer record so that readers can tell a complete snapshot from a partial one.

Unlike ordinary Kafka topics, which may use log compaction, the metadata log uses snapshots followed by truncation. Once a snapshot exists that covers everything up to some offset, the older log segments up to that point can be safely deleted.

Who creates snapshots

Every controller and every broker builds its own snapshots from its own in-memory state, independently. Because all servers apply the same committed records in the same order, their snapshots at the same offset describe exactly the same state. There is no need to ship snapshots around for routine cleanup.

Snapshots for lagging servers

Suppose a broker was offline for a day and, while it was gone, the leader deleted old segments. When the broker returns and asks for a record that no longer exists, the leader replies that the position is too old and points to its latest snapshot. The broker then downloads that snapshot in chunks using a dedicated snapshot-fetch request, loads it, and continues from the snapshot’s end offset by fetching ordinary records.

sequenceDiagram
    participant B as Lagging broker
    participant L as Leader controller
    B->>L: Fetch from offset 100
    L-->>B: Offset too old, snapshot available at 5000
    B->>L: Fetch snapshot chunk 1
    L-->>B: Chunk 1
    B->>L: Fetch snapshot chunk 2
    L-->>B: Chunk 2
    B->>B: Load snapshot and rebuild state
    B->>L: Fetch from offset 5000
    L-->>B: Regular records
        

A raw log is not useful until it is turned into a picture the broker can use quickly.

The metadata image

Each broker maintains an immutable in-memory picture of the cluster called the metadata image. It answers questions such as “who leads partition seven of orders?” in a fraction of a microsecond because it is just data in memory. Immutable means the picture, once built, is never modified. Any thread can read it safely without locks.

Deltas

When new committed records arrive, the broker does not rebuild the entire image from scratch. It collects the new records into a delta, which describes only what changed. Applying the delta to the previous image produces a new image that shares most of its structure with the old one. This makes updates cheap even in very large clusters.

The loader and the publishers

A component called the metadata loader watches the log. It reads committed batches, builds deltas, produces new images and hands both the delta and the new image to a set of listeners called publishers. Each publisher cares about a specific part of the change and reacts to it.

flowchart LR
    LOG["Metadata log - committed records"] --> LD["Metadata loader"]
    SN["Latest snapshot"] --> LD
    LD --> D["Delta - what changed"]
    D --> IMG["New immutable image"]
    IMG --> P1["Replica manager"]
    IMG --> P2["Coordinators"]
    IMG --> P3["Config and quota handlers"]
    IMG --> P4["Client metadata cache"]
        

What happens when a change fails to apply

If the loader cannot apply a batch, for example because of a bug or corrupted data, the broker records a load error and raises alarms through its metrics. Failing loudly is intentional. A broker running with a stale or wrong picture of the cluster could make harmful decisions, so operators are expected to notice and act.

The metadata log is also how the cluster decides which brokers are trustworthy at any given moment.

Joining the cluster

When a broker starts, it first contacts the active controller to register itself. It presents its identifier, a unique incarnation identifier for this particular run, its listeners, its rack and the range of features it supports. The controller checks these, appends a registration record and starts tracking the broker. Newly registered brokers begin in a fenced state.

Fenced and unfenced

A fenced broker is one that is not allowed to lead partitions and is not treated as a healthy destination for new leaders. A broker becomes unfenced only after it has caught up with the metadata log to a recent enough point. This rule stops a broker that has not yet loaded the latest cluster picture from being handed responsibility it cannot handle correctly.

Heartbeats

After registering, each broker sends periodic heartbeats to the active controller. A heartbeat tells the controller three things: I am alive, this is how far I have read in the metadata log, and this is whether I want to be fenced or shut down. If heartbeats stop for longer than the session timeout, the controller fences the broker and moves leadership of its partitions to other replicas.

The metadata log evolves over time. A version system lets a cluster of mixed software agree on what is allowed.

The metadata version

The cluster stores a single number called the metadata version, kept as a feature level record in the log. It controls which record formats and behaviors are permitted. Newer software can understand newer record types, but the controller will not write them until the cluster-wide version allows it.

The safe upgrade dance

Feature flags beyond the metadata version

The same mechanism carries other feature levels, such as the level that controls the format of the quorum itself. Brokers and controllers advertise the range of versions they support when they register, and the controller refuses to raise a feature beyond what every member can handle. This protects the cluster from silently splitting into incompatible halves.

Who exactly the voters are is itself a piece of agreed information, and Kafka has two ways of handling it.

The static quorum

In the original KRaft design, the list of voters is written into every server’s configuration file. It is simple, but changing it is painful. Adding or replacing a controller means editing files and restarting every node in a careful order. If different nodes hold different lists, the quorum can disagree about what a majority even is, which is dangerous.

The dynamic quorum

Newer Kafka releases introduced dynamic quorum membership. Instead of a fixed list in configuration, the current voter set is stored inside the metadata log itself as a special record, and it changes through the same Raft process as everything else. Servers use a bootstrap list only to find the quorum when they start. Operators can then add or remove controllers with administrative commands while the cluster keeps running.

flowchart LR
    S1["New controller starts as observer"] --> S2["Catches up using snapshot and log"]
    S2 --> S3["Admin requests add voter"]
    S3 --> S4["Leader records new voter set in the log"]
    S4 --> S5["Majority commits the change"]
    S5 --> S6["Node is now a voter"]
        

A design is only as good as its behavior on the worst day. Here is what the metadata log does when things break.

The metadata log is the most sensitive data in the cluster. Protect it accordingly.

What makes it sensitive

Anyone able to write to the metadata log can create topics, grant themselves permissions, change credentials and reshape the whole cluster. Anyone able to read its files can see topic names, access rules and, depending on your setup, stored credential material. That is why access to controllers and their disks must be tightly limited.

Authorization data lives in the log

In KRaft, the standard authorizer keeps access control entries inside the metadata log rather than in an external store. That means every broker sees a consistent and current set of rules, and rule changes take effect quickly. It also means that a corrupt or tampered log could change who is allowed to do what, which is another reason to guard controller access.

A healthy metadata log is quiet. Good monitoring tells you about trouble long before users feel it.

Questions your dashboards should answer

Families of metrics to track

Logs worth reading

Controller logs record elections, leadership changes, snapshot creation and quorum membership changes. Brokers log registration, fencing, metadata loading and failures to apply records. During any incident, gather the controller logs from all voters together and line them up by time, because the story of an election is spread across several machines.

Kafka ships tools that let you look inside the metadata log without guessing.

Practical uses

No design is free. A clear view of both sides helps you plan capacity and expectations.

ZooKeeper era versus KRaft era

Metadata is small compared with message data, but its performance profile is unusual. Knowing what drives it prevents nasty surprises.

What grows with the cluster

The size of the metadata image is driven by counts, not by traffic. The more topics, partitions, replicas, configurations, access rules and registered brokers you have, the more memory the image takes and the more records a snapshot contains. Doubling the message volume changes almost nothing here. Doubling the partition count changes a great deal.

Where latency comes from

The time to commit a metadata change is roughly the time for the leader to write the records, plus one network round trip to the fastest majority of followers, plus the time those followers take to write to disk. That means three things dominate: disk write latency on voters, network latency between voters, and how loaded the controller thread is. Improve those and commits become faster. Adding more brokers changes nothing here.

The cost of a burst

Some events cause a sudden flood of records. When a broker with thousands of partition leaderships dies, the controller must choose new leaders for all of them and record each one. When a large batch of topics is created by an automated tool, the same happens. A well-sized cluster absorbs these bursts in moments, but a cluster pushed close to its limits may show visible delays in administrative operations while it works through the queue.

Partition counts and good hygiene

KRaft raises the practical ceiling on partitions, but it does not make unlimited partitions free. Each partition still costs memory, file handles, replication work and recovery time. A healthy practice is to review topics regularly, delete those that are abandoned and resist creating partitions “just in case”. The metadata log will thank you with smaller snapshots and quicker restarts.

Let us tie every concept together by following one small cluster through an eventful day.

Our cluster has three dedicated controllers, named C1, C2 and C3, and four brokers. C1 is the active controller, and the current epoch is seven. The metadata log has been running for months, and each server holds a recent snapshot.

sequenceDiagram
    participant C1 as Controller C1 - epoch 7 leader
    participant C2 as Controller C2
    participant C3 as Controller C3
    participant B as Brokers
    Note over C1: Hardware fault
    C2->>C1: Fetch times out
    C3->>C1: Fetch times out
    C3->>C3: Election timeout fires, epoch 8
    C3->>C2: Request vote for epoch 8
    C2-->>C3: Vote granted
    C3->>C2: Begin epoch 8 as leader
    B->>C3: Fetch committed records
    C3-->>B: Records, epoch 8
        

What this day shows

Every event above is an ordinary change to a shared story. New topics, changed settings, failed brokers and dead controllers all became records or elections, and every server that read the committed story ended up with the same picture. There was no special recovery mode, no manual copying and no external database to reconcile. That is the practical beauty of treating the cluster’s brain as a log.

You do not need to memorize every setting, but you should understand what each family of settings controls and why it exists.

Identity and roles

Quorum discovery

Two styles exist. The static style lists every voter explicitly, with identifier and address, in a voters setting. The dynamic style provides only a bootstrap list of addresses, and the true voter set is read from the log. Mixing the two styles by accident is a classic source of confusion, so pick one approach per cluster and document it clearly.

Timing and liveness

Storage and snapshots

Comparing KRaft with what came before, and with other systems, sharpens your understanding of its choices.

ZooKeeper’s approach

ZooKeeper is a general-purpose coordination service that stores small pieces of data in a tree of nodes and uses its own agreement protocol among an ensemble of servers. Kafka used it as an external database of cluster facts. ZooKeeper is well built, but as an outside system it had its own configuration, its own security, its own capacity limits and its own failure behaviors, all of which Kafka operators had to master in addition to Kafka.

What KRaft changes conceptually

Why an event log suits Kafka in particular

Kafka’s whole existence is built around the idea that a durable, ordered log is a powerful way to share state between many machines. The KRaft design applies this very idea to Kafka’s own state. This is sometimes described as the system eating its own cooking. The code that copies log data between machines was already battle-tested, so the team could extend it rather than write something brand new for metadata.

Relationship to other Raft-based systems

Many organizations still have clusters born in the ZooKeeper era. The migration path shows how the metadata log takes over.

Kafka provides a supported migration approach that moves a live cluster from ZooKeeper to KRaft without downtime for clients. The idea is to introduce a KRaft controller quorum next to the existing ZooKeeper-based controller, let the quorum take control, copy the metadata across, and finally retire ZooKeeper.

flowchart TB
    A["ZooKeeper-based cluster"] --> B["Add KRaft controllers in migration mode"]
    B --> C["Metadata copied into metadata log"]
    C --> D["Brokers restarted in KRaft mode one by one"]
    D --> E["Dual-write - rollback still possible"]
    E --> F["Finalize - ZooKeeper retired"]
        

These habits separate calm operations from nervous ones.

Common mistakes to avoid

Each of these looks convenient in the short term and causes pain in the long term.

The metadata log is not a lab curiosity. It runs the event streaming backbone of many companies.

Raft beyond Kafka

Kafka joins a family of systems that rely on Raft or similar consensus for their control state, including distributed key-value stores, service-discovery tools and distributed SQL databases. Engineers who learn the ideas in this tutorial will recognize them again and again: leaders, terms, majorities and replicated logs are the shared vocabulary of modern distributed systems.

No. The metadata log describes the structure and rules of the cluster. Consumer offsets are kept in a separate internal topic managed by the group coordinator.

Because metadata changes must be strictly ordered. One partition gives one global order that every server can replay to reach the same state.

No. Only controller voters vote. Brokers are observers that read the log but do not affect the majority.

Existing partitions with healthy leaders keep serving reads and writes for a while, but no leadership can change and no metadata operation can succeed. Restoring a majority of voters restores normal operation.

Yes technically, but replication of data partitions would be limited to the number of brokers, so you lose the durability benefits that come from multiple replicas. The controller count and broker count are independent choices.

It works and is fine for development, but it is not recommended for production because the two workloads compete for resources and failures affect both roles at once.

A compacted topic keeps the latest record for each key. The metadata log is cleaned using snapshots: a complete picture at a point in time is saved, and older segments are deleted once they are no longer needed.

Typically a matter of moments, dominated by the timeout used to detect that the leader is silent plus the election itself. It is much faster than the old model, since the new leader does not have to reload state from an external system.

Pull-based reading is simpler and more robust. A broker that misses something just asks again from where it left off, and the leader does not need to track or retry deliveries to hundreds of brokers.

With dynamic quorum support, yes. Voters can be added or removed one at a time through administrative commands. With a static quorum, changes require coordinated configuration updates and restarts.

Not if the quorum is healthy. Other voters hold the same history and snapshots. A node that loses its own snapshot or log can reformat and recover from the quorum. Backups are still wise for disaster scenarios.

Not directly. Message traffic does not pass through the metadata log. However, extremely large amounts of metadata, such as a huge number of partitions, increase memory use and the time needed for loading and administrative operations.

A stable, single active controller with steady epoch, together with brokers that are keeping up with the latest committed metadata offset. Those two signals reveal most trouble early.

No. Clients interact with brokers, and administrative requests are routed to the active controller. Ordinary applications never read or write the metadata log themselves, which protects the cluster’s most sensitive state from accidental damage.

Every controller in the quorum is a voter, meaning it stores the log and takes part in elections. Only one voter at a time is the leader, called the active controller, which is the sole server that appends new metadata records and answers administrative requests.

The identifier proves that all nodes belong to the same logical cluster. A node formatted for a different cluster is rejected, which prevents an accidental merge of two unrelated clusters that would mix incompatible histories.

No. Adding voters raises fault tolerance but slightly increases the work needed for each commit, because a bigger majority must confirm. Speed comes from fast disks, low network latency and a lightly loaded controller thread, not from a larger quorum.

The KRaft metadata log turns Kafka’s brain into an ordinary, replicated, ordered log. A small quorum of controllers agrees on that log using a pull-based variant of Raft, the active controller is the only writer, and every broker follows the committed records to build an immutable in-memory picture of the cluster. Snapshots keep the log short, epochs keep leadership honest, and metadata versions keep upgrades safe. Understanding these few ideas lets you design, run and troubleshoot modern Kafka clusters with confidence.