Hi Joe, Thanks for your questions.
For *MaxPersistentFanout* and *MaxPersistentFanoutBytes* — yes, the system will stop delivering to persistent subscribers that exceed the current configured limit, rather than dropping the entire message. For example, if MaxPersistentFanout = 10 and the topic "/a/b/c" currently has 15 persistent subscribers, BifroMQ will deliver to the first 10 (deterministically ordered) and then stop fanout to the remaining 5. The relevant throttling event will be emitted. The behavior for MaxPersistentFanoutBytes is similar — recipients are admitted until the total payload bytes budget is reached, then delivery stops for the rest. For *MaxGroupFanout* — the limit applies to the *number of matched shared-subscription groups* per message, not the number of members within a group. (The number of members per group can be controlled separately via the tenant-level runtime setting *MaxSharedGroupMembers*) Therefore, MaxGroupFanout does not change how a matched shared group itself behaves — only how many distinct groups are included in delivery. As for estimating appropriate values — this really depends on factors such as available resources, workload patterns, and business requirements, so it’s best decided with a combination of operational metrics and business-level considerations. Best regards, On Wed, Aug 13, 2025 at 8:08 PM gujiaweijoe <[email protected]> wrote: > Hi Yonny, > > Thank you for your proposal. I have a few questions regarding the behavior > when a persistent-related throttle is triggered: > > > For MaxPersistentFanout and MaxPersistentFanoutBytes — will the > system drop entire messages, or will it drop only some recipients to stay > within the limit? From the proposal, it seems to drop recipients. Could you > clarify what policy will be applied? > > > > For MaxGroupFanout — if this throttle is triggered, will the system > drop newly subscribed recipients, or is there a different expected behavior? > > > > Since these settings are hot-reloadable, is it possible to estimate > appropriate values based on the cluster size? > > > > > > Best regards, > Gu Jiawei (Joe) > > > 原始邮件 > > > 发件人：Yonny Hao <[email protected]> > 发件时间：2025年8月13日 17:20 > 收件人：dev <[email protected]> > 主题：[Discuss] BIP-002 Runtime Settings for Limiting Fanout Scale > toPersistent Sessions > > > > Hello all, > > > I’d like to start a discussion on *BIP-002: Runtime Settings for Limiting > Fanout Scale to Persistent Sessions( * > > https://cwiki.apache.org/confluence/display/BIFROMQ/BIP-002%3A+Runtime+Settings+for+Limiting+Fanout+Scale+to+Persistent+Sessions > *)* > <https://cwiki.apache.org/confluence/display/BIFROMQ/BIP-002%3A+Runtime+Settings+for+Limiting+Fanout+Scale+to+Persistent+Sessions *)*> > . > > > This feature helps operators better control persistent-session fanout in > > multi-tenant scenarios, preventing *DistService* and *InboxService* > > hotspots caused by large persistent subscriber sets or many > shared-subscription groups with persistent members. > > > The proposal introduces three *tenant-level, runtime-configurable* settings: > > > - > > > *MaxPersistentFanout* – caps the number of persistent sessions per > message. > - > > > *MaxPersistentFanoutBytes* – caps the total bytes fanned out to > persistent sessions per message. > - > > > *MaxGroupFanout* – caps the number of shared-subscription groups per > topic. > > > I’ve started the implementation in my forked branch: > https://github.com/popduke/bifromq/tree/feat-max-persistent-fanout-limit > > > Looking forward to your thoughts and suggestions. > > Best regards, > > -- > Yonny(Yu) Hao -- Yonny(Yu) Hao
