Aglet

Record a per-class queue fairness contract

Fairness stays reviewable only when service is measured by class rather than by one queue total. Document which classes compete, what service or wait relationship is expected, and how a noisy class is handled. Keep evidence for both balanced and skewed arrivals so future drift has a meaningful comparison.

Keep the lesson for the next incident

  1. Define service expectations

    State the class scope, eligibility rules, allocation policy, and oldest-wait review condition. Explain whether shares are equal, weighted, or partitioned, and identify the queue or worker setting that enforces the choice. Avoid a fairness label without a measurable relationship.

  2. Preserve class fixtures

    Keep equal, skewed, and new-class arrival cases with per-class ready, claim, completion, and oldest-wait expectations. Re-run after priorities, queue topology, worker reservations, or job duration changes alter competition. Include the same worker count and queue assignments in each record so share changes remain interpretable.

  3. Monitor drift by interval

    Compare class service and wait across bounded intervals, watching for a class with ready work but no claim or a sudden share change after a configuration edit. Review arrival mix and eligibility before changing allocation. Assign ownership when a new class enters the queue.

What to carry forward

The durable lesson is a class-specific allocation rule backed by oldest-wait and service-share evidence. Preserve equal, skewed, and new-class fixtures. Reopen review when queue topology, priorities, worker reservations, or job shape changes which classes compete for available service.

Technical background: Rails guides.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow