Matriz Requisição × Estado da Chave

A (Aquisição)

Estado da chave	Ação do servidor	Resposta	Momento
Não registrada	Registra (expiração = agora+lease), emite token	`A`+token+owner+key	Imediatamente
Registrada + expirada	Renova (agora+lease), novo token	`A`+token+owner+key	Imediatamente
Registrada + holder válido + `wait=0`	Não enfileirar	`T`+owner+key	Imediato
Registrada + holder válido + `wait>0`	Enfileirar, resposta pendente	`A` ou `T`+owner+key	Ao adquirir por release/expiry, ou `T` quando wait expira
Fila ou capacidade do servidor no limite	Não enfileirar	`B`+owner+key	Imediato

O caminho de liberação é justo em ordem FIFO: quando o detentor faz R, é repassado diretamente ao detentor da fila que está esperando na frente (sem nova disputa, com um novo token).
Apenas o caminho de expiração não é FIFO.
Um owner igual ao holder atual não recebe tratamento especial. Ele não autoriza retornar active token nem renovar lease; aplicam-se as regras comuns de uma key retida.
Respostas podem chegar fora de ordem; o cliente associa pelo owner ecoado. R (Liberação)

Estado da chave	Ação do servidor	Resposta
Registrada + token confere, com alguém na fila	Repassa diretamente a quem está esperando na frente (novo token)	`R`+token+key
Registrada + token confere, sem ninguém na fila	Exclui a chave	`R`+token+key
Registrada + token não confere	Nada (o lock permanece)	`N`+token+key
Não registrada	Nada	`N`+token+key

Quando a Expiração É Processada

O modo single processa a expiração de forma preguiçosa (lazy) — uma chave que passou de sua expiração é assumida na hora pela próxima aquisição (a segunda linha acima), e uma varredura separada de 5 segundos limpa as chaves expiradas sem ninguém na fila. Assim, uma liberação em uma chave que expirou mas ainda não foi varrida pode receber R em vez de N.
No modo cluster, o líder aguarda a próxima entrada de um deadline min-heap que valida token e faz commit por consenso do comando Expire antes de remover a key. Assim diferenças de clock não dividem o estado do lock.