What types of client quotas does Kafka support and how do byte-rate versus request-rate quotas differ?

**Why quotas exist (capacity view).** On a shared cluster, one misbehaving or runaway client can saturate disk, network, or CPU and starve everyone else. Quotas cap per-client resource use so the cluster's capacity is shared predictably. (Configuring them as a security/control lever is a separate concern; here we care about reading the throughput and throttle signals.) **Quota entities (who a quota applies to).** A quota is attached to one of: - **client-id** — the `client.id` a client sets (weak isolation, client-controlled). - **user** — the authenticated `KafkaPrincipal` (strong, server-controlled). - **(user, client-id)** — most specific. Kafka resolves the most specific match, falling back through a defined hierarchy down to a cluster default. Quotas are stored in the metadata (KRaft) / formerly ZooKeeper and managed with `kafka-configs.sh --alter --add-config 'producer_byte_rate=...' --entity-type clients|users`. **The three quota types:** 1. **producer_byte_rate** — max bytes/sec a client may *produce* into a broker. Defends inbound network + disk write capacity. Units: bytes/sec, per broker. 2. **consumer_byte_rate** — max bytes/sec a client may *fetch* from a broker. Defends outbound network. Per broker. 3. **request_percentage** (request-rate quota, KIP-124) — the percentage of broker thread time the client may use across the network threads and I/O (request-handler) threads. The ceiling is `n × 100%` where n = `num.io.threads + num.network.threads` (so a value of 200 ≈ two full threads). This protects **CPU**, the dimension byte quotas miss: a client sending huge numbers of tiny requests, doing aggressive metadata refresh, or causing expensive fetches consumes thread time disproportionate to its bytes. **Byte-rate vs request-rate — the key difference.** Byte quotas bound *data volume* (network/disk). Request quotas bound *processing time* (CPU). A client can be well under its byte quota yet still hammer the broker with request volume; only request_percentage catches that. Conversely a few large requests are cheap on threads but heavy on bytes. Real protection usually needs both. **Enforcement mechanics (throttling, not rejection).** Kafka does not drop requests; it *delays* responses. It measures each client's rate over a sliding window defined by `quota.window.size.seconds` (default 1s) and `num.quota.samples` (default 11) — i.e. ~11 one-second samples. When the measured rate exceeds the quota, the broker calculates the delay D that, applied to the current request, brings the average back to the quota, and holds the response for D. Modern clients honor the returned throttle time and back off; the broker also mutes the channel so the slow-down is cooperative. Observable via `produce-throttle-time-avg/max`, `fetch-throttle-time-avg/max` (client side) and per-broker throttle metrics. **Edge cases / gotchas:** - Quotas are **per broker**, not cluster-wide: a `producer_byte_rate=10MB/s` lets a client do 10 MB/s *to each broker it leads partitions on*, so effective cluster throughput scales with broker fan-out. - A too-small window or sample count makes throttling bursty/jittery. - Throttling can masquerade as latency or even client timeouts if quotas are aggressive and clients are old; rising throttle-time metrics are the tell. - request_percentage above 100 is normal — it's a percentage of *total* thread capacity (sum of threads), not a single core.