Channel Exclusivity: A Batch Is on Auction or Market — Never Both
The atomic guard that prevents double-publishing, and why it matters when buyers see the same lot in two places.
If the same batch could be published to the market and listed in an auction at once, the platform would be lying to two different buyer groups about availability. The buyer who wins the auction expects to get the lot. The buyer who hits "Buy now" on the market expects the same. One of them is going to be disappointed, and disputes follow.
The guard
The publishing RPCs (market-publish, auction-create) share an atomic database guard: a batch row carries a published_channel enum (none / market / auction), and the RPCs use a CAS (compare-and-swap) update that only succeeds if the current channel is none. If the swap fails — meaning the other channel got there first — the second RPC returns an error and rolls back.
Why atomic
Without atomicity, two simultaneous "publish" requests could both read published_channel = none and both write their own channel. The CAS ensures exactly one wins. Atomic at the database level, not at the application level — because the application can be racing against itself across two server processes, and the only safe single point of truth is the database row.
Channel switch
If a batch needs to switch channels (didn’t sell on auction, want to relist on market), the unpublish-RPC sets published_channel = none and the new publish proceeds. The F5 auction no-sale auto-relist uses this exact path: when an auction lot doesn’t hit reserve, the cron unpublishes the auction and republishes to market in one transaction.