Recipe: Distributed Lock Service

MicroRaft can back a Java distributed lock service when lock ownership, fencing, and failover semantics must stay strongly consistent under partition and recovery.

Typical lock-service state machine

  • lock create, acquire, renew, and release commands
  • owner identity, fencing token, and expiry metadata
  • wait queues or lock-scoped sequencing state
  • explicit revocation or timeout transitions

Why Raft fits lock ownership

  • lock services depend on single-writer semantics, not best-effort coordination
  • fencing tokens map naturally to ordered committed log entries
  • leadership and quorum rules support safe ownership transitions after failure

Design rules that matter

  • prefer fencing-token designs over simple boolean locks
  • define lease expiry and retry behavior before exposing the API
  • treat duplicate client retries as part of the contract, not an edge case