Channel Exclusivity: eine Batch ist auf Auction oder Market - nie beides
Der atomare Guard gegen Double-publishing, und warum das zaehlt, wenn Kaeufer denselben Lot an zwei Stellen sehen.
Wenn derselbe Batch gleichzeitig auf dem Market published und in einer Auction listed sein könnte, würde die Plattform zwei verschiedenen Buyer Groups über Availability lügen. Der Buyer, der die Auction gewinnt, erwartet das Lot zu bekommen. Der Buyer, der auf dem Market "Buy now" klickt, erwartet dasselbe. Einer von beiden wird enttäuscht sein, und Disputes folgen.
Die Guard
Die Publishing RPCs (market-publish, auction-create) teilen eine atomic Database Guard: Eine Batch Row trägt ein published_channel Enum (none / market / auction), und die RPCs nutzen ein CAS (compare-and-swap) Update, das nur erfolgreich ist, wenn der aktuelle Channel none ist. Wenn der Swap fehlschlägt — weil der andere Channel zuerst da war — returned die zweite RPC einen Error und rollt zurück.
Warum atomic
Ohne Atomicity könnten zwei gleichzeitige "publish" Requests beide published_channel = none lesen und beide ihren eigenen Channel schreiben. CAS stellt sicher, dass genau einer gewinnt. Atomic auf Database Level, nicht Application Level — weil die Application gegen sich selbst über zwei Server Processes racen kann, und der einzige sichere Single Point of Truth die Database Row ist.
Channel switch
Wenn ein Batch Channels wechseln muss (nicht auf Auction verkauft, Relist auf Market), setzt die Unpublish-RPC published_channel = none und der neue Publish läuft weiter. Der F5 Auction No-sale Auto-relist nutzt genau diesen Pfad: Wenn ein Auction Lot Reserve nicht erreicht, unpublisht der Cron die Auction und republisht in einer Transaction auf Market.