Lease, lock com tempo e fencing token sem falsa sensação de exclusão

O problema

Quando há risco de dois processos fazerem a mesma coisa ao mesmo tempo, o atalho costuma ser:

• pega lock
• coloca TTL
• segue a vida

Isso ajuda em vários casos.

Mas também cria um engano comum:

“agora só existe um executor de verdade”

Nem sempre.

Se o processo atrasar, pausar, perder o lease ou ficar zumbi, o sistema pode continuar sofrendo concorrência mesmo com lock temporário.

Modelo mental

Vale separar três ideias:

• lock
• lease
• fencing token

Lock passa sensação de exclusão.

Lease dá uma permissão temporária.

Fencing token ajuda o destino a rejeitar ação antiga quando existe dúvida sobre quem ainda é o dono válido.

Quando a equipe mistura tudo isso, o TTL parece mais poderoso do que realmente é.

Exemplo simples

Imagine dois workers processando exportação por tenant.

O worker A pega lease por 30 segundos.

Depois ele sofre pausa longa.

O lease expira.

O worker B pega lease novo e continua.

Se o worker A voltar e ainda conseguir gravar resultado, você teve dois “donos” agindo.

É aí que fencing token ajuda:

• cada lease novo recebe token maior
• o recurso aceita só token mais recente

Sem isso, o lease protege menos do que o time imagina.

O erro comum

O erro comum é tratar Redis lock com TTL como exclusão distribuída perfeita.

Ele pode ser suficiente em cenários simples.

Mas não resolve sozinho:

• pausa longa de processo
• clock estranho
• renovação mal feita
• escritor velho terminando depois

Outro erro comum é nem perguntar se o problema realmente pede exclusão tão forte.

Às vezes basta:

• idempotência
• deduplicação
• serialização por fila

O que normalmente ajuda

Normalmente ajuda responder:

• o que exatamente estou protegendo?
• o recurso de destino consegue rejeitar escrita velha?
• o lease precisa de renovação?
• o risco operacional aceita sobreposição rara ou não?

Na prática, isso costuma separar casos em que:

• lease simples basta
• fencing token vale a pena
• lock é sinal de modelagem ou coordenação mal resolvida

Como um senior pensa

Quem já viu job zumbi costuma perguntar:

• se esse processo perder o lease, ele ainda consegue causar dano?
• o destino conhece “quem é mais novo”?
• estou vendendo exclusão forte onde só tenho heurística razoável?
• consigo operar expirado, renovação e takeover sem ambiguidade?

Essas perguntas reduzem muito a falsa confiança.

Ângulo de entrevista

Esse tema aparece em schedulers, jobs distribuídos, concorrência por recurso e design de coordenação.

O entrevistador quer ver se você entende:

• que TTL não é exclusão mágica
• que fencing token resolve classe específica de problema
• que às vezes o melhor desenho evita lock forte no primeiro lugar

Resposta forte costuma soar assim:

“Eu trataria lease como permissão temporária, não como exclusão perfeita. Se o processo antigo ainda puder escrever depois de perder o lease, eu consideraria fencing token ou outra proteção no recurso de destino. TTL sozinho não me dá confiança total.”

Takeaway direto

Lease ajuda bastante.

Só não merece a fama de resolver concorrência sozinho.