The Inventory That Lied to Customers
#customer-support-escalation — 47 orders, 5 units in stock
Support: Customers charged, then cancelled. Product page showed "In Stock" while warehouse had zero. Redis cache lagged 60 seconds behind PostgreSQL truth.
The trap: page reads stale cache · charge payment · verify warehouse too late · cancel and refund.
Your task
Fix `ConsistencyAwareInventorySystem` in `inventory_system.py`: honest availability UX when cache is stale, verify warehouse before charging on low-stock items, update cache on every write.
Book: eventual consistency is abstract · Prod: 42 customers charged then cancelled.
Skills you'll prove
Interview Tip
When asked about eventual consistency or caching, say: "Eventual consistency isn't a bug — it's a trade-off for performance. The danger is when you build UX that assumes immediate consistency on top of an eventually consistent system. I fixed an inventory overselling problem where the product page read from a 60-second stale cache. Customers saw '5 in stock' when the warehouse had 0. The fix was threefold: show honest stock levels when the cache is stale ('Low Stock — Confirm Availability'), verify against the source of truth before charging payment for low-stock items, and update the cache immediately after each order instead of waiting for the TTL. The key principle: the closer stock gets to zero, the more you should bypass the cache and check the source of truth. This is called a read-through with freshness check pattern."