Prompt and scope
This tests protocol design at the API boundary. The referenced document is an active Internet-Draft published May 23, 2026, not an RFC; state that status before using it. The design must remain safe if a deployment adopts only part of the proposal.
What the interviewer is evaluating
- A precise distinction between policy metadata and current available quota.
- Structured-field parsing, multiple windows, quota units, and partition keys.
- Interaction with 429, Retry-After, gateways, CDNs, and stale cached responses.
- Privacy and denial-of-service risks from exposing limits.
- Client backoff that treats hints as non-binding and tolerates missing or malformed fields.
Recommended answer structure
Define the quota dimensions and ownership first. Show one response containing a policy and current limit, then explain how a client schedules work. Add cache and intermediary rules, security constraints, observability, and a rollout plan with a feature flag so the draft can change without breaking clients.
Deep dive: make the headers useful without promising capacity
Separate policy from current state
RateLimit-Policy describes a named quota, such as "tenant";q=1000;w=60. RateLimit reports the available quota and effective window, for example "tenant";r=420;t=23. A policy can contain multiple items and variable windows. The server remains the authority: these values are hints, not a lease or service-level guarantee.
Define partition and unit semantics
Document whether one quota unit means a request, byte, token, or weighted operation. A partition key may distinguish tenants or resources, but never put an email, raw user ID, or secret into a header. Keep policy names stable and versioned; changing units without changing the policy identifier makes client pacing unsafe.
Coordinate 429 and Retry-After
Return Retry-After when the server knows when a rejected request may be tried again. If both fields are present, clients give Retry-After precedence; RateLimit helps pace future work. The draft does not require a particular throttling algorithm, so clients still need capped exponential backoff, jitter, deadlines, and an idempotency rule for writes.
Treat caches and intermediaries as participants
RateLimit values on a cached response may be stale and should be ignored when the response has positive current age. An intermediary unaware of the quota semantics must not make the response look more permissive. A gateway that enforces a stricter limit may communicate that stricter policy, while telemetry records origin and gateway decisions separately.
Protect availability and privacy
Do not expose a large quota window that reveals traffic volume or lets an attacker amplify requests. Cap the ratio between available quota and effective window, validate incoming structured fields, and ignore malformed values. Lowering advertised values during saturation is allowed, but clients must still handle a rejection even when the last hint looked healthy.
Sample answer
“I would version a named policy per tenant and operation, define the unit, and emit policy metadata separately from current remaining quota. The draft is an Internet-Draft, so clients treat both fields as optional hints. Retry-After controls a rejected request; RateLimit paces future work. CDNs mark cached values stale, gateways never make origin limits appear looser, and partition keys contain no identifiers. SDKs parse structured fields defensively, use jitter and a shared queue, and expose metrics for advertised versus enforced limits before we enable the contract gradually.”
Common failure modes and fixes
- Calling the draft an RFC → Record its Internet-Draft status and isolate it behind a versioned contract.
- Using remaining quota as permission → Treat it as a hint; the server may still reject under saturation.
- Returning user identifiers in partition keys → Use opaque, low-cardinality names and review privacy exposure.
- Trusting cached headers → Ignore stale values and let the origin enforce the limit.
- Retrying every 429 immediately → Honor
Retry-After, add jitter, and enforce method-specific idempotency.
Scoring rubric and self-check
Score policy/state separation, units and partitions, 429 interaction, cache behavior, privacy, client pacing, rollout safety, and metrics. A strong answer explains what each header means, what it cannot guarantee, and how a client behaves when fields are absent, stale, or malformed.
Follow-ups and extensions
What if a response has two windows?
Select the constraint that will be exhausted first for pacing, while retaining all items for observability. The SDK should not silently collapse windows with different units or partition keys.
Should a successful response include RateLimit?
It may, but the client must not assume every response contains it. Emit only when useful for the product and ensure caches cannot turn old values into current promises.
How do you roll out a changing draft?
Negotiate a header profile or policy version, log parser fallbacks, canary by SDK version, and keep 429 plus Retry-After behavior stable while the new fields are optional.
Which metrics prove the contract works?
Track advertised and enforced limits, stale-header decisions, 429 rate, retry amplification, queue delay, eventual success, and privacy-safe partition cardinality by gateway and SDK version.