Problem Statement
Support per-queue dispatch gates for ephemeral Redis (redis-pubsub)
Context:
Currently, the ephemeral Redis Channels implementation does not support per-queue dispatch gates Instead, it "fails-open," defaulting to a ConstantGate (1.0 budget) for all channels.
Requirement:
Since the GateFactory abstraction is already implemented in PR #72, the redis-pubsub flow should be updated to achieve functional parity with the redis-sortedset implementation.
Why this matters:
This allows users who prefer the lower latency/overhead of the ephemeral implementation to still benefit from granular, metric-based throttling for specific high-traffic or low-priority topics.
Pros of adding support:
-
Parity: Ensures functional consistency between the Sorted Set and Pub/Sub drivers.
-
Traffic Isolation: Allows users to throttle low-priority ephemeral topics (e.g., logging or non-critical metrics) using Prometheus saturation without impacting higher-priority real-time streams.
-
Safety: Prevents a sudden burst in a Pub/Sub channel from potentially overwhelming the Inference Gateway.
Cons of adding support:
-
Increased Complexity: Adds logic to a driver that is intended to be the "lean/simple" alternative to Sorted Sets.
-
Performance Overhead: Introducing gating checks adds a small amount of latency to the "fire-and-forget" nature of the Pub/Sub flow.
Proposed Solution
Proposed Changes:
- Config Parsing: Update the ephemeral Redis configuration parser to recognize
gate_type and gate_params fields in the Multiple Queues Configuration
- Factory Integration: Ensure the
redis-pubsub flow passes these parameters to the GateFactory during initialization.
- Throttling Support: Enable metric-based throttling (e.g.,
prometheus-saturation) for specific ephemeral topics.
Alternatives Considered
Leave as is.
Willingness to Contribute
Yes, I can submit a PR
Additional Context
No response
Problem Statement
Support per-queue dispatch gates for ephemeral Redis (redis-pubsub)
Context:
Currently, the ephemeral Redis Channels implementation does not support per-queue dispatch gates Instead, it "fails-open," defaulting to a
ConstantGate(1.0 budget) for all channels.Requirement:
Since the
GateFactoryabstraction is already implemented in PR #72, theredis-pubsubflow should be updated to achieve functional parity with theredis-sortedsetimplementation.Why this matters:
This allows users who prefer the lower latency/overhead of the ephemeral implementation to still benefit from granular, metric-based throttling for specific high-traffic or low-priority topics.
Pros of adding support:
Parity: Ensures functional consistency between the Sorted Set and Pub/Sub drivers.
Traffic Isolation: Allows users to throttle low-priority ephemeral topics (e.g., logging or non-critical metrics) using Prometheus saturation without impacting higher-priority real-time streams.
Safety: Prevents a sudden burst in a Pub/Sub channel from potentially overwhelming the Inference Gateway.
Cons of adding support:
Increased Complexity: Adds logic to a driver that is intended to be the "lean/simple" alternative to Sorted Sets.
Performance Overhead: Introducing gating checks adds a small amount of latency to the "fire-and-forget" nature of the Pub/Sub flow.
Proposed Solution
Proposed Changes:
gate_typeandgate_paramsfields in the Multiple Queues Configurationredis-pubsubflow passes these parameters to theGateFactoryduring initialization.prometheus-saturation) for specific ephemeral topics.Alternatives Considered
Leave as is.
Willingness to Contribute
Yes, I can submit a PR
Additional Context
No response