Page History

...

Here are the rejected alternatives.

1. Raise broker max only; no per-group override

A misconfigured group can write millions of updates without ever triggering an update (count-based) snapshot.single broker-level setting forces all share groups on the cluster to use the same value. Different groups have different write profiles. A low-traffic group benefits from a low value (fast recovery), while a high-traffic group benefits from a high value. Without a per-group override, operators must pick one value that compromises for all groups.
Additionally, since all groups on the same __share_group_state partition share log-pruning behavior, one group set very high can delay pruning for unrelated groups on the same partition.

2. Per-group override only; keep broker max at 500. 

The broker ceiling becomes the effective hard cap for any acts as a hard cap on every per-group value (per-group value
Leaving 500 in place forces operators is between(200, broker_value)). If we keep the broker max at 500 means, per-group overrides cannot exceed 500 either, so high-traffic groups cannot benefit from the per-group config. In this case operators would have to raise the broker config anyway to take advantage of per-group tuning.ceiling immediately anyway to use the new per-group setting meaningfully. Basically the per-group config is not of much use without the ceiling raise.

3. Keep the floor at `0` (raise only the ceiling)

The PR thread surfaced consensus that `0` Raising only the ceiling (between(0, 1000)) is of minimum risk and it is intact with the documented 0 semantics avoids any upgrade-time validation failure. But based on the PR thread discussion , there is a consensus that 0 and other very small values waste disk by writing a full snapshot for nearly every state change, and no real-world workload benefits from them..