Lease-Based Assignment

Concepts Covered

• Temporary resource reservation
• Lease tokens
• Expiration windows
• Assignment races
• Confirmation workflows
• Stale lease cleanup
• Retry behavior

1. Intent

Lease-Based Assignment temporarily reserves a scarce resource for one workflow while the system waits for final confirmation.

In a ride-matching system, a driver is scarce supply. Once the matcher offers a trip to a driver, other matching workers should not offer that same driver to another rider during the decision window.

A lease says:

driver d_42 is reserved for ride r_99 until 10:15:30

If the driver accepts, the lease becomes a committed assignment. If the driver rejects or times out, the lease expires and the driver can re-enter the available pool.

2. The Problem Without This Pattern

Without a lease, concurrent matchers can race.

matcher A sees driver d_42 available for rider r_1
matcher B sees driver d_42 available for rider r_2
matcher A sends offer
matcher B sends offer
driver receives conflicting trips

This is not just a messy UI problem. It creates broken marketplace state. Riders may think a driver is coming. Drivers may accept one trip while another workflow still believes it owns the driver.

The system needs a middle state between "available" and "fully assigned."

3. How The Pattern Works

A lease is usually written with an atomic conditional operation:

UPDATE driver_state
SET status = 'leased',
    leased_to_ride_id = 'ride_99',
    lease_token = 'lease_abc',
    lease_expires_at = now() + interval '15 seconds'
WHERE driver_id = 'driver_42'
  AND status = 'available';

Only one worker should win that update. The winner sends the offer. Losers try another candidate.

Follow-up operations include the lease token:

confirm assignment only if lease_token = lease_abc
release lease only if lease_token = lease_abc

The token prevents an old worker from accidentally modifying a newer lease.

4. When To Use It

Use this pattern when:

• a resource can only serve one workflow at a time
• final confirmation takes time
• concurrent workers can see the same candidate
• failures or timeouts should release the resource
• the system needs a clear pending state

Examples:

• driver assignment
• inventory reservation
• seat reservation
• job claiming
• temporary payment authorization workflow ownership

5. When Not To Use It

Avoid this pattern when the resource is not scarce, when duplicate assignment is harmless, or when the workflow can be solved with a simple idempotency key.

Also avoid overly long leases. A long lease can hide supply from the system and reduce throughput.

6. Data And Operational Model

Typical fields:

resource_id
status
leased_to_workflow_id
lease_token
lease_expires_at
version
updated_at

Workers need a cleanup path:

leased and lease_expires_at < now -> available

Cleanup can happen lazily during reads, through periodic jobs, or inside the assignment service.

7. Failure Modes

Important failure modes:

• lease expires while the user is still deciding
• worker sends offer but crashes before recording notification state
• stale worker confirms an old lease
• clock skew makes expiration ambiguous
• cleanup job releases a lease too early
• clients retry confirmation after the lease changed

Lease tokens, server-side timestamps, idempotent confirmation APIs, and clear state transitions reduce these risks.

8. Tradeoffs

Leases prevent double assignment, but they introduce temporary unavailability.

If many drivers are leased and then time out, the marketplace looks supply-constrained even though drivers technically exist. If leases are too short, valid drivers may lose offers before they can respond.

The lease duration is a product and operational tuning decision.

9. Related Systems And Concepts

• Uber-Style Ride Matching System
• Dispatch Matching
• Idempotency
• Retry With Backoff And Jitter