Backend Engineering · Engineering Foundry challenge level: Advanced

API Usage Budget Service

Design a low-latency service that enforces tenant usage budgets across regions while remaining operable during partial failure.

All challengesSuggested practice time: 80 minutes

Original prompt

What you are building

Design the API, data model, and consistency strategy for a service that decides whether a tenant may consume a requested number of API units. Budgets reset on defined calendar boundaries, traffic is multi-region, and downstream services need a fast allow-or-deny decision.

Engineering Foundry originalNo company association

Deliverables

Reservation/consumption API and idempotency contract.
Budget, reservation, and ledger data model.
Concurrency and multi-region consistency strategy.
Failure, timeout, and reset-boundary behavior.
Reconciliation and operator recovery plan.
Load, correctness, and observability tests.

Constraints

The hot decision path targets low double-digit millisecond latency.
Retries must not consume the same logical request twice.
The design must state whether and where overshoot is possible.
Reset boundaries use an explicit configured timezone.

Success criteria

Strict and tolerant enforcement modes are distinguished.
Idempotency and concurrent reservations are concrete.
Regional failure behavior matches the stated overshoot policy.
Ledger reconciliation can detect and explain divergence.

Suggested workflow

Define strictness and overshoot policy.
Write the request and idempotency contract.
Model reservations, consumption, expiry, and reset.
Compare coordination and regional-allocation strategies.
Trace retry, partition, clock, and reconciliation scenarios.

Attempt before reveal

Build your deliverable independently.

Use the prompt, constraints, and workflow first. Guidance offers considerations and questions - not a canonical solution.

Reveal guidanceDirections and questions to test

Tradeoffs to test

Compare a globally coordinated counter with preallocated regional budget slices.
A reservation lifecycle can separate authorization from final consumption.
Use stable request identity and a ledger to make reconciliation explainable.

Reveal common mistakesFailure patterns worth checking

Claiming strict global enforcement with independent regional counters.
Leaving reservation expiry undefined.
Using wall-clock reset logic without timezone and boundary tests.
Treating the cache as both the authority and the audit ledger.

Reveal stretch goalsOptional ways to extend the deliverable

Support hierarchical organization and project budgets.
Add soft warnings before a hard enforcement threshold.

Optional solution worksheet

Prepare your approach for discussion.

Capture your reasoning, then copy a plain-text summary you control.

Session only - not saved.Refreshing or leaving this page clears every worksheet field and self-review choice. Nothing is uploaded or officially submitted.

Approach summary

Key decision

Important tradeoff

Failure mode or edge case

Validation or testing plan

Reflection

Optional solution URLThis link remains in the current browser session and is included only if you copy the summary.

Nothing is sent when you copy.

Optional community discussion

Compare reasoning, not rankings.

Discuss this challenge in the Engineering Foundry community if you choose. Share your own work, explain assumptions, critique ideas rather than people, and remove confidential or proprietary material.

Discuss this challenge

Loading Engineering Foundry…

Backend Engineering · Engineering Foundry challenge level: Advanced

API Usage Budget Service

Design a low-latency service that enforces tenant usage budgets across regions while remaining operable during partial failure.

All challengesSuggested practice time: 80 minutes

Original prompt

What you are building

Engineering Foundry originalNo company association

Deliverables

Reservation/consumption API and idempotency contract.
Budget, reservation, and ledger data model.
Concurrency and multi-region consistency strategy.
Failure, timeout, and reset-boundary behavior.
Reconciliation and operator recovery plan.
Load, correctness, and observability tests.

Constraints

The hot decision path targets low double-digit millisecond latency.
Retries must not consume the same logical request twice.
The design must state whether and where overshoot is possible.
Reset boundaries use an explicit configured timezone.

Success criteria

Strict and tolerant enforcement modes are distinguished.
Idempotency and concurrent reservations are concrete.
Regional failure behavior matches the stated overshoot policy.
Ledger reconciliation can detect and explain divergence.

Suggested workflow

Define strictness and overshoot policy.
Write the request and idempotency contract.
Model reservations, consumption, expiry, and reset.
Compare coordination and regional-allocation strategies.
Trace retry, partition, clock, and reconciliation scenarios.

Attempt before reveal

Build your deliverable independently.

Use the prompt, constraints, and workflow first. Guidance offers considerations and questions - not a canonical solution.

Reveal guidanceDirections and questions to test

Tradeoffs to test

Compare a globally coordinated counter with preallocated regional budget slices.
A reservation lifecycle can separate authorization from final consumption.
Use stable request identity and a ledger to make reconciliation explainable.

Reveal common mistakesFailure patterns worth checking

Claiming strict global enforcement with independent regional counters.
Leaving reservation expiry undefined.
Using wall-clock reset logic without timezone and boundary tests.
Treating the cache as both the authority and the audit ledger.

Reveal stretch goalsOptional ways to extend the deliverable

Support hierarchical organization and project budgets.
Add soft warnings before a hard enforcement threshold.

Optional solution worksheet

Prepare your approach for discussion.

Capture your reasoning, then copy a plain-text summary you control.

Session only - not saved.Refreshing or leaving this page clears every worksheet field and self-review choice. Nothing is uploaded or officially submitted.

Approach summary

Key decision

Important tradeoff

Failure mode or edge case

Validation or testing plan

Reflection

Optional solution URLThis link remains in the current browser session and is included only if you copy the summary.

Nothing is sent when you copy.

Optional community discussion

Compare reasoning, not rankings.

Discuss this challenge

API Usage Budget Service

What you are building

Deliverables

Constraints

Success criteria

Suggested workflow

Build your deliverable independently.

Tradeoffs to test

Backend Engineering deliverable self-review

Prepare your approach for discussion.

Compare reasoning, not rankings.

API Usage Budget Service

What you are building

Deliverables

Constraints

Success criteria

Suggested workflow

Build your deliverable independently.

Tradeoffs to test

Backend Engineering deliverable self-review

Prepare your approach for discussion.

Compare reasoning, not rankings.