CONCEPT Cited by 2 sources
Forward progress¶
Definition¶
Forward progress is the liveness requirement that a system eventually completes attempted work even when individual participants fail or are partitioned. For leadership change specifically: "If an existing elector fails, a different elector can initiate a new round" and the system must not be permanently stuck holding a lock or waiting on a dead participant.
Sugu Sougoumarane canonicalises forward progress as the key axis differentiating the two leader-election families:
"The main advantage of a lock-free approach is that it naturally supports forward progress. If an existing elector fails, a different elector can initiate a new round without knowledge of the state or age of an older elector. For this reason, there is no need to depend on timeouts."
"However, the lock-based approach introduces a problem with forward progress. For example, an elector may successfully obtain a lock and then crash or become partitioned out of the rest of the system. This will prevent all other electors from ever being able to repair this situation." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-5-handling-races)
How the two families preserve it¶
Lock-free¶
Forward progress is free: newer-wins ordering on proposal numbers means a crashed elector never blocks a later one. A fresh elector just picks a higher proposal number and proceeds; followers reject the old one's stale messages on arrival.
Lock-based¶
Forward progress must be manufactured via a time component:
"To resolve this, lock-based systems must introduce a time component: any elector that obtains a lock must complete its task within a certain period of time, after which the lock is automatically released."
The auto-release-on-timeout converts an infinite-block failure mode into a bounded-delay one. The timeout is in tension with false auto-release under slow-but-alive electors; systems tune it with generous margin above normal completion time plus clock-skew allowance (see concepts/leader-lease for the follow-on application of the same time-component to leader leases).
Why lock-based is still preferred at scale¶
Despite needing to manufacture forward progress, Sugu argues lock-based wins at scale because stable-leader + leader lease dominates the cost structure of reads (no quorum round-trip) and simplifies the operational ecosystem around the leader (backups, schema changes, workflows). Forward progress is a real concern but a solvable one in the lock-based family; the lack of a stable leader in the lock-free family is a permanent one.
Seen in¶
- sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-5-handling-races — canonical wiki introduction of forward progress as the primary axis distinguishing lock-based from lock-free leader election; the "elector crashes holding the lock" failure mode and the time-component-fix are named explicitly.
- sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-6-completing-requests — commit-path retry discipline: a leader that cannot reach durability "can keep retrying, but it must not attempt to cancel the request." The retry-not-cancel rule is a commit-path-specific forward-progress sub-invariant; cancellation belongs to the elector during a leadership change, not to the struggling leader.