Add a per-reservation maximum quantity cap

Nobody has started this yet — be first.

Business impact

Nothing stops a single Reserve call from claiming a SKU's entire remaining stock in one request. For a genuine flash sale (the exact scenario this project is built around), that means one request -- a bug in a client, a scraper, or someone gaming the sale -- can claim all 100 units before anyone else gets a chance, defeating the point of a fair sale entirely.

Problem

checkMaxReserveQuantity exists only as a panicking TODO(ticket-18) stub; there is no way to cap how much a single Reserve call can claim.

Current behavior

A Reserve call over any intended cap currently panics with "TODO(ticket-18): checkMaxReserveQuantity not implemented" instead of being rejected cleanly.

Expected behavior

Service.SetMaxReserveQuantity(n int64) opts a Service into rejecting any single Reserve call asking for more than n units with a new ErrQuantityTooLarge, even when there's enough total stock to satisfy it. The default (unset) behavior is unlimited, exactly as today -- this is opt-in, not a behavior change for existing callers.

Steps to reproduce

go test ./tickets/tests/... -run TestTicket18 -v
Observe: Reserve over the configured cap panics with "TODO(ticket-18): checkMaxReserveQuantity not implemented".

Why this matters

The cap must be checked before any database work happens (no point opening a transaction for a request that's going to be rejected on quantity alone), and it must not affect Service instances that never call SetMaxReserveQuantity -- Reserve's existing call sites and this project's own test suite must keep working unchanged.

Suggested approach

Reserve already has an early quantity check (qty <= 0) right at the top, before it opens a transaction -- the new check belongs right after it, and only when a cap has actually been configured. Look at checkMaxReserveQuantity's stub and its call site in Reserve for where this is already wired up.

Acceptance criteria

With no cap configured, Reserve behaves exactly as before for any quantity
With a cap configured, a Reserve call over the cap is rejected with ErrQuantityTooLarge, without touching the database
A Reserve call at or under the cap still succeeds normally
tickets/tests/ticket18_test.go passes

Verification

TEST_DATABASE_URL=postgresql://... go test ./tickets/tests/... -run TestTicket18 -v

Hints (0/2)

Try it without hints first — the reading is the exercise.

Working on this ticket

Work on a branch named for the ticket — that's what you'll submit.

Branch off your fork

$git checkout -b feat/max-reserve-quantity

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin feat/max-reserve-quantity

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Inventory Reservation Service

Oversell-proof stock reservations under extreme concurrent contention: 100 units, 50,000 simultaneous "Buy Now" clicks, and exactly 100 must succeed.

Fork on GitHub

Download

Setup

Inventory Reservation Service

git clone <your-fork>
cd GolangDevTraining/inventory
docker compose up --build   # Postgres + 2 hot-reloading app replicas + Adminer

Two app replicas are on by default, not opt-in: the TTL reaper's claiming and the reservation hot path's atomicity guarantee only prove anything interesting with more than one process sharing the same Postgres and the same SKU row. App replica 1 is reachable at ; Postgres at . Seeded on startup: (10 units) and (5,000 units). Verify with and .