The problem

Gold and silver bars and jewelry sold at prices tied to the international gold rate — computed live, so a stale number never reaches a customer.

Decisions

1. No stored prices. Only weight, margin and labor are saved; the price is computed from the live rate at the moment of viewing. Changing VAT in the admin updates every product at once (measured, then reverted).
2. The price locks when an item goes into the cart — tested by moving the rate on purpose: the product page changed, the cart held.
3. Rate sources sit behind an adapter. The candidate changed three times — public data, a brokerage API, an unlimited REST feed — and the collection core never changed.

What broke — and the fix

1. One bad setting took the whole product list down with a 500: the price function threw and nothing caught it. Failures are now isolated per product, and only that product shows “price pending”.
2. A development dummy rate wobbled ±0.5% and looked alive, with nothing to stop sales. Production now fails closed, and products leave sale when the rate is more than 60 minutes old.

Results

• Price function checked against 300,000 random samples · 8 E2E and 6 unit cases
• 30 row-level security policies
• Five-stage adversarial audit — 0 critical defects
• Three unauthenticated rate sources cross-checked within 0.13%
• Rate collected every 5 minutes by pg_cron, with firing and loading logged