Return available stock for a specific warehouse
Product pages display total stock across both warehouses, although East cannot ship West inventory. A customer sees four brake kits available when their shipping warehouse has none.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- REST contracts · SQL · Tenant isolation
Estimated field mix
- Backend50%
- Database engineering30%
- Security20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
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 retailer sells bicycle parts from East and West warehouses. Cart reservations last ten minutes, payment callbacks arrive late, and warehouse counts occasionally need correction. The exercise has no real orders or payment integration.
Setup prerequisites
- Relational modeling
- Concurrent API requests
- State transitions
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Return on-hand, reserved, and available quantities for the selected warehouse and SKU.
- Unknown SKUs return a documented not-found response.
- Reject warehouse IDs outside the caller's retailer scope.
Implementation constraints
- Available means on-hand minus active reservations; do not silently substitute another warehouse.
Verification to include
- Read the same SKU from East and West with different balances.
- Deny a foreign warehouse and reject an empty SKU.
Deliverables
- Warehouse stock endpoint and response examples
Rollout and recovery
Switch the synthetic product page lookup by warehouse behind a flag; restore the earlier lookup if contract errors rise.
Value of the work
For the engineer: Practice inventory invariants and timed state transitions while balancing customer experience with operational repair.
For the team: Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes.
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.