Quando vários processos ou vários servidores tocam simultaneamente no mesmo recurso (conta, pedido, estoque, tarefa em lote etc.), surge disputa (contenção). Mutexes ou semáforos embutidos na linguagem só são válidos dentro de um único processo — se há vários processos, ou eles estão distribuídos em vários servidores, é preciso um meio de exclusão mútua que ultrapasse os limites do processo.
O Ticketing é exatamente um servidor de lock e um conjunto de clientes para esse problema: exclusão mútua distribuída que atravessa os limites de processo e servidor. O cliente se conecta ao servidor de lock via TCP, adquire (acquire) uma chave (key) nomeada, e após passar pela seção crítica, faz a liberação (release).
O Ticketing não usa JSON, e sim um protocolo de quadros com campos binários de largura fixa. Depois do despacho de 1 byte de op, lê-se um número fixo de bytes por op como comprimento, e apenas a última chave é lida até a quebra de linha (\n). A análise é mais uma leitura de deslocamento (offset) do que uma análise propriamente dita, o que gera menos sobrecarga por requisição do que analisar JSON a cada vez.
A cada aquisição de lock, o servidor também entrega um token de fencing u64 monotonicamente crescente. Se o recurso protegido for programado para validar a monotonicidade desse token, é possível recusar o acesso de um cliente que acordou atrasado — depois da expiração do lease — usando um token menor. Com isso, a segurança se mantém mesmo que o próprio servidor de lock não seja perfeitamente consistente a cada instante — o que é especialmente importante durante uma janela de failover.
Funciona mesmo com apenas 1 servidor (modo single), mas se for necessária operação sem interrupção, monta-se um cluster com no mínimo 2 servidores. O cluster não elege um ativo por consenso (quórum), e sim por prioridade: um é eleito ativo e os demais se tornam standbys que recebem replicação em tempo real. Se o ativo morrer (inclusive por reinicialização) ou encerrar de forma graciosa, um standby assume. Para mais detalhes sobre esse comportamento, veja a página Princípio de funcionamento.
Sobre o mesmo protocolo binário, oferecemos clientes oficiais em 8 linguagens: Rust, Java/Kotlin, JavaScript/TypeScript, Python, C#, Go, Ruby, C/C++. Cada linguagem expõe a API da maneira mais natural para seu ecossistema — por exemplo, linguagens da família async/await usam API assíncrona, enquanto Go/Ruby/C usam bloqueio + thread em segundo plano. O protocolo é idêntico byte a byte em todas as linguagens. Veja como instalar e exemplos por linguagem na página Bibliotecas.