Objects & APIs (stale inventory)

REAL PROBLEM: A shopper buys the last unit on mobile. The purchase succeeds on the server, but the app still shows "1 in stock" on the product screen. Another tap tries to buy again — or a second shopper thinks the item is available when it is not. WHY this matters: Stale inventory creates oversells, angry customers, and support fires. The UI is not "a little behind" — it is answering from a cache or local object that was never refreshed after a write. Two shapes of "product" (list card vs detail vs cart line) can disagree on the same stock field. HOW it usually happens: The app keeps a local product object after the first fetch. Checkout posts a purchase but never invalidates or updates that object. Or the list screen maps stockCount while the detail screen maps quantityAvailable from a different payload shape — same entity, inconsistent contract. GUIDED QUESTIONS: After a successful purchase, which source of truth should win for stock? What must happen to local/cached objects? How do you keep the product shape consistent across screens? CONCEPT: Objects should share one contract for an entity (one Product shape). APIs that write must be followed by freshness strategy: invalidate cache, refetch, or patch the local object from the response. Showing yesterday's stock after a write is an apis-freshness + objects-consistent-shape failure — not a "UI glitch."

Key takeaways

• WHY this matters: Stale inventory creates oversells, angry customers, and support fires.
• HOW it usually happens: The app keeps a local product object after the first fetch.
• GUIDED QUESTIONS: After a successful purchase, which source of truth should win for stock?

Sign in to complete activities, save progress, and use the AI Coach.