Skip to main content

Overview

Fairness queues prevent one category of messages from monopolizing processing resources. By using disambiguators, you can ensure messages are processed fairly across different tenants, users, or categories.
Fairness queues are currently only supported with the Redis broker.

The problem

Without fairness, a burst of messages from one source can delay others: Tenant B and C must wait for all of Tenant A’s messages to process.

With fairness

Fairness distributes processing across categories:

Using disambiguators

Publishing with disambiguators

Include a disambiguator when publishing:

Consuming with fairness

Enable fairness in consume options:

How it works

With fairness enabled:
  1. Messages are stored in sub-queues based on disambiguator
  2. The consumer rotates through sub-queues in round-robin fashion
  3. Each consume operation pulls from the next sub-queue

Use cases

Multi-tenant applications

Prevent one tenant from affecting others:

Priority levels

Implement soft priority with multiple queues:

User-based fairness

Prevent a single user from overwhelming the system:

Queue size with fairness

When using fairness, queue.size() returns sizes for each sub-queue:

Configuration options

Best practices

Use identifiers that represent your fairness boundaries:
  • Tenant ID for multi-tenant apps
  • User ID for user fairness
  • Region for geographic distribution
  • Priority level for soft prioritization
Track the size of each sub-queue to detect imbalances:
Too many unique disambiguators can impact performance. Consider bucketing:

Limitations

  • Only available with Redis broker
  • Round-robin is fixed (no weighted fairness)
  • Empty sub-queues are checked (slight overhead)

Alternatives

If fairness queues don’t fit your needs:
  1. Separate queues: Create distinct queues per category
  2. Priority option: Use PublishOptions::priority() for priority-based ordering
  3. Custom routing: Implement your own routing logic with multiple queues