RabbitMQ / Advanced: ordered ownership, retained replay and accepted recovery / Lesson 16
Policies, limits and resource budgets
Review effective settings and overflow consequences before treating queue limits as harmless capacity knobs.
On this page
Lesson goals
- Distinguish declaration-time properties from dynamically applicable policies.
- Calculate bounded resource exposure and explain overflow outcomes.
Not every property can be changed by policy
Policies apply selected settings to matching resources within a virtual host. They are useful for runtime-adjustable values such as supported TTL or length settings, while queue type is a declaration-time choice and cannot be switched by policy. Client arguments, ordinary policies and operator policies can interact with key-specific precedence rules. Do not summarize the entire system as one universal last-writer-wins rule. Inspect effective values for the exact resource, queue type and version. Policy patterns and priorities also matter; equal-priority overlapping matches can be ambiguous. Keep application ownership and platform guardrail ownership visible in the review.
A ready-message limit is not a total memory cap
Queue maximum length can limit ready-message count or message-body bytes under the documented behavior. Unacknowledged deliveries do not count toward the ordinary ready-length limit, and body-byte limits exclude properties and overhead. A queue with a small ready limit can therefore coexist with substantial client and broker resource use. Prefetch, message sizes, replicas and retained dead letters contribute additional exposure. The arithmetic example separates body bytes for a declared ready backlog from a larger whole-system budget that is deliberately not estimated. Label decimal and binary units explicitly rather than treating every number followed by MB as interchangeable.
Overflow chooses which work is lost or rejected
A drop-head strategy removes or dead-letters older ready work when the limit is reached, whereas supported reject-publish behavior rejects newer publication and can produce a publisher nack when confirms are enabled. Supported strategies differ by queue type. A message routed to several queues can be accepted by some and rejected by another, so a nack is not proof no destination received it. Retry using the original operation identity and account for duplicates. Choose overflow from business loss and backpressure requirements, not merely the graph shape desired during an incident. A length limit silently changing work coverage is a correctness decision.
Compute only the cost the inputs support
The local example multiplies a synthetic five-hundred-message ready limit by a two-kilobyte maximum body size. It produces one million body bytes before metadata, indexes, replication and client buffers. It is not physical disk sizing or an exact memory ceiling. The JSON design record scopes a reject-publish length policy to a named queue family in one vhost and requires publisher outcome handling. It is not an API payload and is never applied. A real policy review should list all matching resources, current effective settings and expected behavior at the threshold before a separately authorized change.
ready_limit = 500
max_body_bytes = 2000
ready_body_budget = ready_limit * max_body_bytes
assert ready_body_budget == 1000000
print(ready_body_budget)1000000One million body bytes excludes properties, overhead, replicas and unacknowledged messages.
{"vhost":"lab-orders","queue_family":"lab.labels.*","intended_ready_limit":500,"overflow":"reject-publish","publisher_must_handle_nacks":true}The family notation is descriptive, not a broker regex or an applied administrative policy.
Verify both normal and threshold behavior
A meaningful acceptance plan includes below-limit traffic, overflow, an unavailable dead-letter target and an outstanding unacked window. Compare unique business coverage and publication outcomes, then confirm unrelated queues remain outside the pattern. Do not raise a guardrail solely to clear an alarm without checking sustainable drain capacity and disk reserve. This lesson applies no policy, queries no management API and performs no load test. Its arithmetic and design fixture validate assumptions only. Actual precedence, enforcement timing and resource use require version-specific authorized evidence rather than inference from a parsed JSON object.
Common errors and fixes
A policy is expected to change a classic queue into quorum in place.
- Why it happens
- Declaration-time type was confused with dynamic optional settings.
- How to fix it
- Plan a new compatible topology and message migration.
- Prevent it next time
- Classify each setting by lifecycle before changes.
A ready-byte limit is called the brokerโs total memory limit.
- Why it happens
- Message bodies were confused with total resource cost.
- How to fix it
- Budget overhead, unacked work, replicas and reserve separately.
- Prevent it next time
- Label the exact quantity every estimate covers.
A rejected multi-queue publish is blindly retried as entirely absent.
- Why it happens
- Partial destination acceptance was ignored.
- How to fix it
- Retain stable operation identity and reconcile destination outcomes.
- Prevent it next time
- Include partial-routing acceptance in retry reviews.
Check your understanding
1. Does max-length=500 count every message already delivered but unacknowledged?
Show worked solution
Not under the ordinary ready-length contract described here. Unacknowledged deliveries add separate exposure, and byte limits concern bodies rather than full memory cost. Review prefetch, consumers and queue-type-specific behavior along with effective policy before using the limit as a capacity claim.
2. Can a publisher nack mean one bound queue accepted the operation while another rejected it?
Show worked solution
Yes. Multi-destination routing can have partial acceptance under the documented overflow behavior. A retry may therefore duplicate work at an accepting destination. Preserve original identity and use a reviewed duplicate-safe contract instead of assuming every negative outcome means nothing anywhere was stored.
Key takeaways
- Policies have scope, precedence and lifecycle boundaries.
- Limits and overflow are business coverage and backpressure decisions.