noCV
AADMIT-103 · Define load and fairness

Record the fairness decision for small and large report tenants

Practice briefTaskFoundational

A single tenant's weekly exports occupy every available slot while small interactive reports wait behind them.

Focused work estimate
2h + prerequisites
Priority in the scenario
Medium
Engineering practice
Scheduling tradeoffs · Fairness

Estimated field mix

  • System design60%
  • Distributed systems40%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

A fictional analytics product lets customers schedule expensive reports at the top of the hour. The API remains available only if report work is admitted and cancelled predictably.

Setup prerequisites

  • Create a local scheduler model and synthetic report jobs.
  • Use fake execution providers; no customer queries or candidate code run on worker hosts.

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • Compare FIFO, per-tenant limits and weighted scheduling.
  • Define fairness and starvation expectations.
  • Document how unknown report cost is classified.

Implementation constraints

  • Use a small synthetic tenant set and avoid hiring or user scoring.

Verification to include

  • Evaluate a mixed small/large workload against the chosen rule.
  • Show the behavior when one tenant continuously submits work.

Deliverables

  • Fairness decision record

Rollout and recovery

Review the chosen policy with the workload model; retain configuration for bounded tuning.

Value of the work

For the engineer: Practice workload modeling, fairness and cancellation architecture.

For the team: Review controllable operating costs and predictable customer-facing overload behavior.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.