Decision
Use Valkey as the first deployable KV backend behind the lease-store protocol. Keep the protocol backend-neutral so a stronger-consistency backend can be added without changing target or HTTP code.
Required implementation
- One atomic acquire script: create lease only when free/expired and increment a monotonic fencing counter.
- Atomic renew script requiring matching lease id, owner, and fencing token.
- Atomic compare-and-delete release.
- TTL stored by the backend; server time/TTL result is authoritative.
- Request-id result cache for idempotent retries.
- Namespaced keys suitable for standalone and clustered deployments.
- Connection pooling, authentication, TLS configuration, deadlines, reconnect/backoff, and health checks.
- No use of unsafe
GET then SET races.
- Document failover/replication assumptions and where fencing is enforced downstream.
Acceptance tests
- Backend contract suite passes against a real Valkey service.
- 100 concurrent acquire attempts yield one owner and one fencing token generation.
- Expiry followed by reacquire produces a strictly larger token.
- Old owner cannot renew, release, or commit after reacquire.
- Script interruption/retry is idempotent by request id.
- Credentials and lease metadata are redacted from logs where required.
Decision
Use Valkey as the first deployable KV backend behind the lease-store protocol. Keep the protocol backend-neutral so a stronger-consistency backend can be added without changing target or HTTP code.
Required implementation
GETthenSETraces.Acceptance tests