Page History

...

1. StopReplica
2. ControlledShutdown
3. LeaderAndIsr
4. UpdateMetadata

The following requests will not be throttled (unless authorization fails) since they are timing-sensitive:

1. Heartbeat
2. JoinGroup
3. LeaveGroup
4. SyncGroup

All other requests may be throttled if the rate exceeds the configured quota. All requests that may be throttled will have an additional field request_throttle_time_ms to indicate to the client that the request was throttled.The versions of these requests will be incremented.

...

Rather than an absolute request rate, we can use a percentage of maximum request rate and throttle clients only when the broker is running at full capacity. Request rate was chosen instead of percentage to keep the configuration and implementation consistent with existing produce/fetch byte rate quotas.

Exempt timing-sensitive requests such as consumer heartbeat

Consumer requests such as heartbeat are timing sensitive and it is possible that throttling these requests could result in the consumer falling out of the consumer group. However, if we don't throttle some requests, a misbehaving application or a misconfigured application with low heartbeat interval or a client library with a bug can cause broker overload. To protect the cluster from DoS attacks and avoid these overload scenarios, all client requests will be throttled. In most deployments, quotas will be set to a large enough value to provide a safety net rather than very small values that throttle well-behaved clients, so this shouldn't be an issue.