skip to content

What is the difference between static (server.properties) configs and dynamic configs in Kafka, and why does it matter operationally?

level: juniorimportance: must knowfreq 70%

answer

  1. server.properties = restart; kafka-configs = live
  2. dynamic persisted in ZK / __cluster_metadata
  3. read-only / per-broker / cluster-wide update modes
  4. dynamic > static > default precedence
  5. survives restart

basics

~10 s

Static configs live in server.properties and only take effect after a broker restart. Dynamic configs are set with kafka-configs at runtime and apply without restarting the broker, so you can tune a live cluster.

solid answer

~40 s

Static configs are read from each broker's server.properties file at startup; changing one requires editing the file and restarting the broker. Dynamic configs are stored in the cluster metadata (ZooKeeper historically, the __cluster_metadata KRaft log today) and applied at runtime by kafka-configs --alter, so no restart is needed. Not every property is dynamically updatable: Kafka classifies broker configs as read-only (static only), per-broker (dynamic, one broker), or cluster-wide (dynamic, all brokers). Operationally this matters because dynamic configs let you tune things like num.replica.fetchers, log.cleaner threads, or compression on a running cluster, and they survive restarts because they are persisted in metadata. server.properties still provides the bootstrap baseline and any read-only values.

go deeper

for a junior

Know that server.properties needs a restart and kafka-configs changes apply live and persist.

for a middle

Explain the three update modes (read-only/per-broker/cluster-wide) and where dynamic configs are stored.

for a senior

Reason about precedence and when to prefer dynamic tuning over a rolling restart for live operations.

for a principal

Design config-management policy: which knobs stay static for safety vs. exposed as dynamic, and the metadata-durability implications in KRaft.

## The two config sources A Kafka **broker** (a server process in the cluster) gets its configuration from two places: 1. **Static configuration** — the `server.properties` file on that broker's disk. The broker reads this file once, at JVM startup. To change a static value you edit the file and **restart** the broker. Example properties: `listeners`, `log.dirs`, `broker.id`, `process.roles`. 2. **Dynamic configuration** — values set at runtime with the `kafka-configs.sh` CLI (or the `AdminClient` Java API). These are persisted in the cluster's metadata store — in older clusters that was **ZooKeeper**, in modern **KRaft** clusters it is the internal `__cluster_metadata` topic/log. Because they live in metadata, they **survive broker restarts** and are propagated to brokers without a restart. ## Why three categories exist Kafka documents every broker config with an **Update Mode**: - **read-only** — can only be set statically; changing it needs a restart (e.g. `log.dirs`). - **per-broker** — dynamically updatable for a single broker (e.g. SSL keystore paths). - **cluster-wide** — dynamically updatable as a default for every broker (e.g. `log.cleaner.threads`, `num.replica.fetchers`). ## Precedence When the same property is set in more than one place, the effective value follows: **per-broker dynamic > cluster-wide dynamic > static server.properties > Kafka's hardcoded default**. So a dynamic value always wins over `server.properties` for the same key. ## Why it matters operationally Restarting brokers is disruptive: partitions move leadership, the broker re-replicates, and consumers may rebalance. Dynamic configs let you tune a **live** cluster — increase fetcher threads under replication lag, throttle the log cleaner, change default retention — with zero downtime, and the change is durable. You still keep `server.properties` as the bootstrap baseline and the home of read-only values. ## Edge cases - A dynamic config set then later also placed in `server.properties` does **not** override the dynamic value; dynamic still wins. - Deleting a dynamic config (`--delete-config`) makes the broker fall back to the static/default value.

  • If you set a property dynamically and also in server.properties, which wins?
    The dynamic value wins. Dynamic configs take precedence over the static file for the same key; static is only the bootstrap baseline.
  • Where are dynamic broker configs stored?
    In cluster metadata — historically ZooKeeper, in KRaft clusters the internal __cluster_metadata log — which is why they survive restarts.

saying these in an interview costs you the question

  • Saying all configs can be changed dynamically — read-only configs (e.g. log.dirs, listeners core) require a restart.
  • Claiming dynamic configs are lost on restart — they are persisted in metadata.
  • Believing server.properties overrides a dynamic value for the same key.

context

resolving links…