Channel exclusivity: een batch staat op auction of market - nooit allebei
De atomische guard die double-publishing voorkomt, en waarom dat telt wanneer kopers dezelfde lot op twee plekken zien.
Als dezelfde batch tegelijk op de market gepubliceerd en in een auction listed kon worden, zou het platform tegen twee verschillende buyer groups liegen over availability. De buyer die de auction wint verwacht het lot te krijgen. De buyer die op "Buy now" in de market klikt verwacht hetzelfde. Eén van beiden wordt teleurgesteld, en disputes volgen.
De guard
De publishing RPCs (market-publish, auction-create) delen een atomic database guard: een batch row draagt een published_channel enum (none / market / auction), en de RPCs gebruiken een CAS (compare-and-swap) update die alleen slaagt als het huidige channel none is. Als de swap faalt — wat betekent dat het andere channel eerst was — returnt de tweede RPC een error en rolt terug.
Waarom atomic
Zonder atomicity zouden twee gelijktijdige "publish" requests allebei published_channel = none kunnen lezen en elk hun eigen channel schrijven. De CAS zorgt dat er exact één wint. Atomic op database level, niet op application level — omdat de application tegen zichzelf kan racen over twee serverprocessen, en de enige veilige single point of truth de database row is.
Channel switch
Als een batch van channel moet wisselen (niet verkocht op auction, opnieuw listen op market), zet de unpublish-RPC published_channel = none en kan de nieuwe publish doorgaan. De F5 auction no-sale auto-relist gebruikt exact dit pad: wanneer een auction lot reserve niet haalt, unpublisht de cron de auction en republisht naar market in één transactie.