Lorsque plusieurs processus ou plusieurs serveurs manipulent simultanément la même ressource (compte, commande, stock, tâche par lots, etc.), une contention apparaît. Les mutex ou sémaphores natifs d'un langage ne sont valides qu'au sein d'un seul processus — si les processus sont multiples ou répartis sur plusieurs serveurs, il faut un mécanisme d'exclusion mutuelle distinct qui franchit la frontière des processus.
Ticketing est précisément un serveur de verrouillage accompagné d'un ensemble de clients destinés à résoudre ce problème, à savoir l'exclusion mutuelle distribuée qui franchit la frontière des processus et des serveurs. Le client se connecte au serveur de verrouillage via TCP, acquiert (acquire) une clé (key) nommée, puis la libère (release) après avoir traversé la section critique.
Ticketing n'utilise pas JSON mais un protocole de trame composé de champs binaires de largeur fixe. Après le dispatch de l'octet d'opération (op) sur 1 octet, les octets fixes propres à chaque op sont lus selon leur longueur, et seule la clé (key) finale est lue jusqu'au retour à la ligne (\n). Il ne s'agit pas tant d'une analyse syntaxique que d'une simple lecture par décalage, ce qui génère moins de surcharge que l'analyse d'un JSON à chaque requête.
À chaque acquisition d'un verrou, le serveur délivre également un jeton de fencing u64 strictement croissant. Si la ressource protégée vérifie la croissance stricte de ce jeton, elle peut refuser l'accès d'un client qui se réveille tardivement après l'expiration du lease et présente un jeton plus faible. Il en résulte une sécurité préservée même si le serveur de verrouillage lui-même n'est pas parfaitement cohérent à tout instant — un point particulièrement important lors des bascules (failover).
Le serveur fonctionne avec une seule instance (mode simple), mais si l'exploitation sans interruption est requise, un cluster est constitué avec un minimum de 2 nœuds. Le cluster élit un nœud actif non pas par consensus (quorum) mais selon la priorité, les autres nœuds devenant des standby qui reçoivent une réplication en temps réel. Si le nœud actif meurt (y compris lors d'un redémarrage) ou s'arrête proprement (graceful), un standby prend le relais. Pour le détail du fonctionnement, consultez la page Principe de fonctionnement.
Sur le même protocole binaire, des clients officiels sont fournis pour 8 langages : Rust, Java/Kotlin, JavaScript/TypeScript, Python, C#, Go, Ruby, C/C++. Chaque langage expose son API d'une manière naturelle pour son écosystème — par exemple, de façon asynchrone pour les langages de la famille async/await, et de façon bloquante avec un thread d'arrière-plan pour Go/Ruby/C. Le protocole est identique au niveau des octets pour tous les langages. Pour les méthodes d'installation et les exemples propres à chaque langage, consultez la page Bibliothèques.