BlueShop Real-Time Inventory — As Built

What this showcase explains: a warehouse change updates customer-facing availability, then checkout confirms whether the requested quantity can still be reserved.

1. What BlueShop Delivers

The customer sees availability change as warehouse reality changes. Checkout does not trust that screen blindly: it returns to Stock for an authoritative reservation.

Customer visibilityAvailability follows committed warehouse changes.

Fast projections and a live browser stream keep the product page useful and current.

Checkout correctnessThe final unit is decided by Stock.

An atomic reservation guard accepts one valid hold and refuses every request that arrives too late.

Practical example: a stock manager removes damaged units and later records a delivery. The open product page first becomes sold out, then sellable again. If two shoppers race for the final available unit, only one reaches shipping.

2. Warehouse Change Becomes Customer Visibility

The first film shows the complete visible story with burned-in narration.

WAREHOUSE → STOREFRONT / 43.16S

Warehouse Change Flips the Storefront Live

A damage adjustment closes the purchase action. A goods receipt reopens it. The customer does not reload the page and the operator does not coordinate with the storefront.

Open the WebM directly

The warehouse records realityStock validates the adjustment or receipt and preserves the reason as an auditable movement.

A full availability state travels outwardConsumers receive the resulting state rather than an arithmetic delta that could be applied twice.

The open product page followsA snapshot establishes current state; live updates keep the connected customer informed.

3. The Final Unit Is Decided Once

Seeing availability is informative. Receiving a reservation is decisive. The second film shows two independent customers acting on the same last unit.

CONCURRENT CHECKOUT / 31.32S

One Shopper Wins the Last Unit

Both customers begin checkout simultaneously. Stock grants one reservation, lets that customer continue to shipping, and gives the other customer a clear sold-out result.

Open the WebM directly

SHOPPER A

Reservation accepted

The guarded update holds the unit and checkout continues.

One authorityavailable ≥ requested

SHOPPER B

Insufficient stock

The same guard no longer matches. No oversell and no false order.

4. Business Result

01More accurate availabilitySold-out inventory stops looking purchasable to active customers.
02More sellable timeReplenished stock returns to sale without manual storefront coordination.
03No final-unit oversellOne request receives the hold; every later request receives a clear outcome.
04Operational traceabilityReceipts, damage, reservations and releases remain explainable movements rather than silent edits.

TECHNICAL DEEP DIVE

How inventory works

The customer story ends above. The sections below explain ownership, transactions, asynchronous delivery, browser recovery and the database decision that prevents overselling.

5. How Inventory Moves

One path keeps the shop current. A separate path confirms availability at checkout before any unit is reserved.

Two straight flows show warehouse changes reaching the storefront and checkout confirming availability with Stock — Warehouse changes travel outward so the shop stays current. Checkout follows a separate, authoritative path back to Stock before any unit is reserved.

Boundary	Owns	May project	Must never decide
Stock	Quantity, movements, reservations, available-to-sell	Authoritative state and audit ledger	Product merchandising or order lifecycle
Catalog / Storefront	Product presentation and customer interaction	Availability for fast customer reads	Whether the final unit is held
Cart	Checkout orchestration	Reservation identity and status	Stock allocation without Stock confirmation

6. Live Availability Sequence

The browser starts from a database snapshot and then follows full-state changes emitted after committed warehouse transactions.

Sequence from warehouse adjustment through Stock transaction, outbox, Kafka and Catalog to browser availability — The Stock request ends after its local transaction commits. Publication and customer visibility happen asynchronously. The SSE endpoint subscribes to deltas before reading the initial snapshot.

7. Reservation Concurrency

Two requests can reach checkout together. Correctness comes from the database mutation predicate, not request timing or the customer-facing projection.

Sequence where two shoppers request one final unit and the atomic database guard accepts only one — Idempotency prevents one checkout from reserving twice. The availability predicate prevents two independent checkouts from owning the same final unit.

Why this matters: the product page can be briefly stale without corrupting inventory. The authoritative reservation command evaluates current database state.

8. Reservation Lifecycle

A checkout hold either becomes committed order stock, returns through cancellation, or expires safely. Each route keeps quantity changes and reservation state consistent.

Three straight lanes show an active reservation entering the FULFILLED Stock state and later shipping, being cancelled with stock released, or expiring with stock released — `FULFILLED` is the current Stock state name for a reservation committed to an Order; it does not mean Cart owns the business capability of fulfilment. Quantity remains reserved until shipment deducts physical stock. Cancellation and expiry return held quantity. Cleanup claim and release share one transaction, so a release failure leaves the active hold available for the next sweep.

9. Failure and Recovery

Distributed reads can update at different times. Each failure mode stays bounded, while Stock keeps quantity and reservation changes consistent in one transaction.

Database transaction failsQuantity, movement, reservation and outbox effects roll back together.

Kafka publication failsThe outbox retries; committed Stock state remains authoritative.

Projection is delayedVisibility can lag briefly, but the projection cannot award inventory.

SSE disconnectsThe browser reconnects with backoff and obtains a fresh snapshot.

Two checkouts collideThe guarded update accepts one mutation and cleanly rejects the other.

Expired-hold cleanup failsThe claim and release roll back, leaving the hold retryable.