A switch nobody hears is not a switch
The sold-out toggle worked perfectly — the database knew, payment refused — and the till kept selling the item for the whole gap in between. Where availability state actually has to live.
An operator switched a cheese off in the availability list, walked to the till, and sold it anyway. The tile looked normal. The basket took it. Only the final Pay press refused, with a message naming the item. Their words: "way too late then" — and they were right.
The switch was never the problem
Everything downstream worked. The database held the flag. The payment route checked it and refused. The tiles even knew how to draw an out-of-stock state. What nothing did was tell the running screen — the register had loaded its menu at open and was drawing the world as it was that morning. The switch flipped a fact the screen had already stopped listening to.
State has three homes, and all three need the news
Availability lives in the database (the truth), on the server's refusal path (the backstop), and in the memory of every screen currently open (what people actually see). Most systems wire the first two and call it done, because the first two are testable in one process. The third is where the counter conversation happens.
The fix is unglamorous plumbing: the sheet that flips a switch refreshes the register's own menu the moment the server accepts; a slow poll patches the same state so a switch flipped on another device — the back office, a second till — reaches this one within a couple of minutes; and the tile draws the out state loudly enough to read at counter speed, veiled and ringed, not a thin outline over a full-colour photo.
The backstop stays
None of this removes the payment-time check. A screen can always be a step behind — that is what screens are. The refusal at the end is the guarantee; the refreshes exist so it almost never has to fire, because the person at the counter deserves the news before the customer has been quoted a price.