Channel exclusivity: une batch est sur Auction ou Market - jamais les deux

Si le même batch pouvait être publié sur le market et listé dans une auction en même temps, la plateforme mentirait à deux groupes de buyers sur la disponibilité. Le buyer qui gagne l'auction s'attend à recevoir le lot. Le buyer qui clique "Buy now" sur le market s'attend à la même chose. L'un des deux sera déçu, et les disputes suivront.

Le guard

Les publishing RPCs (market-publish, auction-create) partagent un atomic database guard : une batch row porte un enum published_channel (none / market / auction), et les RPCs utilisent un update CAS (compare-and-swap) qui ne réussit que si le channel actuel est none. Si le swap échoue — ce qui signifie que l'autre channel est arrivé le premier — le second RPC retourne une erreur et rollback.

Pourquoi atomic

Sans atomicity, deux requêtes "publish" simultanées pourraient toutes deux lire published_channel = none puis écrire leur propre channel. Le CAS garantit qu'une seule gagne. Atomic au niveau database, pas application — parce que l'application peut racing contre elle-même sur deux server processes, et le seul single point of truth sûr est la database row.

Channel switch

Si un batch doit changer de channel (pas vendu en auction, relist sur market), l'unpublish-RPC définit published_channel = none et la nouvelle publication peut continuer. Le F5 auction no-sale auto-relist utilise exactement ce chemin : lorsqu'un auction lot n'atteint pas reserve, le cron unpublish l'auction et republie vers market dans une seule transaction.