Walk through replica.fetch.max.bytes, replica.fetch.wait.max.ms, and num.replica.fetchers — what each controls and how you'd tune them.

These are all **broker-level** configs governing the follower side of replication. ### `replica.fetch.max.bytes` (default 1048576 = 1 MiB) - **What it does:** The maximum number of bytes the leader will return **per partition** in a single fetch response to a follower. It bounds the batch size pulled for each partition. - **Hard constraint:** It must be **>= the broker's `message.max.bytes` / topic `max.message.bytes`**. Kafka has a safety override so a fetch always returns at least one full record even if it exceeds the limit (otherwise a large message could never replicate), but you should still size this config above your max message to avoid pathological single-record fetches. - **Companion:** `replica.fetch.response.max.bytes` caps the *whole* response across all partitions; `replica.fetch.max.bytes` is per-partition within it. - **Tuning:** Larger values let a behind follower drain more per round-trip (fewer round-trips, faster catch-up) but increase per-fetch memory on both leader and follower. On fat, high-throughput partitions, raising it reduces replication lag. ### `replica.fetch.wait.max.ms` (default 500) - **What it does:** The maximum time the leader will block a follower's fetch request waiting for data when fewer than `replica.fetch.min.bytes` (default 1) bytes are available. This is the **long-poll** timeout for replication. - **Interaction:** Works with `replica.fetch.min.bytes`. With min.bytes=1, the leader returns as soon as any byte is available, so the wait mostly matters when the partition is idle — the request returns empty after the timeout. - **Tuning:** Lower it to reduce the worst-case staleness of a follower (and thus tighten how quickly the high watermark can advance under bursty load), at the cost of more frequent (possibly empty) fetch requests and CPU. Raising it batches more but adds latency. Must stay comfortably below `replica.lag.time.max.ms` so an idle-but-healthy follower isn't dropped from the ISR. ### `num.replica.fetchers` (default 1) - **What it does:** The number of `ReplicaFetcherThread`s each follower broker runs **toward each remote leader broker**. Partitions whose leader is broker X are distributed across these threads. - **Why it matters:** A single fetcher thread processes its assigned partitions sequentially; one large or slow partition can head-of-line-block replication of the others sharing that thread. More threads = more parallelism toward the same leader. - **Tuning:** On clusters with many partitions per broker and/or high write throughput, increasing to 4-8 (sometimes more) markedly reduces replication lag and speeds partition reassignment. The ceiling is CPU/network on the broker; too many threads add context-switching overhead and can overwhelm the leader's request handling. ### Putting it together A follower lagging behind is usually network/round-trip bound (raise `num.replica.fetchers` and/or `replica.fetch.max.bytes`) or, if idle-latency sensitive, you trim `replica.fetch.wait.max.ms`. Always validate against memory (`fetchers * partitions * fetch.max.bytes`), `replica.lag.time.max.ms`, and the max message size constraint.