Is your feature request related to a problem? Please describe.
In our setup, we use MQTT (no Kafka consumer), QoS 1, and require full message retention (no data loss). When a subscriber (customer application) is offline for an extended period, messages accumulate in TBMQ (Kafka-backed persistence). Once the subscriber reconnects, TBMQ replays the backlog at maximum speed, overwhelming the subscriber. Since we cannot control or modify the subscriber application, which immediately ACKs messages and pushes them into an internal asyncio.Queue, the application’s memory usage increases rapidly, eventually causing it to crash.
Describe the solution you'd like
We would like to see outbound rate limiting / throttling for APPLICATION clients at the broker level. Specifically, we would like to be able to:
- Limit message delivery rate per subscriber (e.g., max 100 messages/sec)
- Throttle backlog replay to prevent bulk delivery (currently, delivery is happening at full speed, causing bursts)
- Allow configuring rate-limiting policies directly on TBMQ (not relying on subscriber-side changes)
- Smooth the backlog replay when the subscriber is recovering from being offline, ensuring that messages are delivered in steady chunks instead of all at once
Describe alternatives you've considered
We’ve explored the following broker-side configurations to manage the rate of message delivery:
- Netty backpressure tuning (NETTY_WRITE_BUFFER_LOW_WATER_MARK / NETTY_WRITE_BUFFER_HIGH_WATER_MARK) → helps reduce burst size but does not enforce a fixed rate
- Message delivery strategies (writeAndFlush vs. buffered) → prevents large batches but still does not limit the delivery rate
- Kafka consumer tuning (max.poll.records) → reduces batch size but does not directly limit the rate of delivery to subscribers
- Inflight message limits (max_inflight_messages) → forces PUBACK pacing but does not control message rate per second
- Queue limits (e.g., TB_APP_PERSISTED_MSG_PACK_PROCESSING_TIMEOUT) → introduces delays but still not true rate limiting
These solutions mitigate the issue but do not provide a rate-limiting mechanism at the broker level to control the number of messages sent per second.
Describe the specific rate limit configuration you would like
We would like the ability to set a maximum outbound message rate per client or per topic. For example:
- Max messages per second (e.g., 100 messages/sec per subscriber)
- Max messages per minute (e.g., 5000 messages/minute)
This would allow us to avoid flooding the subscriber with a large volume of messages and control the rate of delivery during backlog replay.
Additional context
- Subscriber uses Python aiomqtt, where ACK is automatic and cannot be delayed or controlled
- Messages are considered delivered by TBMQ as soon as received, even if internally queued
- Current delivery model is effectively batch-driven (Kafka poll → send → wait → repeat), leading to bursty behavior
- A true rate limiter at broker level would significantly improve stability for such clients
Is your feature request related to a problem? Please describe.
In our setup, we use MQTT (no Kafka consumer), QoS 1, and require full message retention (no data loss). When a subscriber (customer application) is offline for an extended period, messages accumulate in TBMQ (Kafka-backed persistence). Once the subscriber reconnects, TBMQ replays the backlog at maximum speed, overwhelming the subscriber. Since we cannot control or modify the subscriber application, which immediately ACKs messages and pushes them into an internal asyncio.Queue, the application’s memory usage increases rapidly, eventually causing it to crash.
Describe the solution you'd like
We would like to see outbound rate limiting / throttling for APPLICATION clients at the broker level. Specifically, we would like to be able to:
Describe alternatives you've considered
We’ve explored the following broker-side configurations to manage the rate of message delivery:
These solutions mitigate the issue but do not provide a rate-limiting mechanism at the broker level to control the number of messages sent per second.
Describe the specific rate limit configuration you would like
We would like the ability to set a maximum outbound message rate per client or per topic. For example:
This would allow us to avoid flooding the subscriber with a large volume of messages and control the rate of delivery during backlog replay.
Additional context