Safety means something forbidden never happens, such as two successful owners for seat 12. Liveness means useful progress eventually happens under stated conditions. Refusing all reservations preserves the ownership safety rule but provides no useful service. A good design must state both the forbidden result and the conditions under which it makes progress.
A client does not inspect every replica. It observes requests, responses, and timeouts. Ask what a successful response promises, what reads may return afterward, and what a timeout leaves unknown. This course derives those contracts before examining Raft and Paxos. You will reason about small executions, not build a production consensus engine. Timing diagrams and log tables are invented examples; their spacing and playback speed are not latency measurements.
State progress conditions and the meaning of a response
Safety can be refuted by one finite bad history. If Ada and Bo each receive a final success for the same unreleased seat, later repair cannot make that history valid. Liveness has a different form. A request waiting now may complete later, so a finite period of silence does not by itself refute an eventual-progress claim. To make the claim useful, name the conditions under which waiting must end. For example, a service might require enough functioning replicas, working storage, continued message delivery, and a sufficiently stable coordinating process. These are assumptions to examine, not hidden guarantees of the network.
Consider a separate paper policy that sends every reservation to one designated machine and never replaces it. While that machine runs, serial execution can preserve the seat invariant. If it stops permanently, every future request waits permanently. The policy has not necessarily violated uniqueness, but it has failed any progress promise covering that failure. Automatically letting another machine take over raises a safety question instead. What evidence tells the replacement which previous commands must be preserved, and what prevents the old machine from continuing to authorize conflicting reservations? Replication protocols must answer those questions together.
Success needs a durability boundary. If a server reports success after changing only volatile memory, a power loss may remove the reservation. If the advertised contract says successful reservations survive that failure, the response came too early. Writing one durable copy protects against a process restart under a suitable storage contract but not necessarily against destruction of that disk. Maintaining additional copies can broaden protection, provided the protocol preserves the acknowledged decision when authority changes. The later replication lessons distinguish local storage, agreement, and execution rather than treating every acknowledgment as equivalent.
A rejection and a timeout convey different information. A valid rejection says that this attempted reservation did not obtain the seat under the service's rules. A timeout says the client stopped waiting without a conclusive response. The reservation may already exist. The next lesson develops this uncertainty from what messages the client can actually observe. Do not assign a fresh operation identity merely because a timer expired. Safe retry behavior requires an explicit contract for identifying one logical request and recovering its result, which a later lesson derives.
Finally, separate a successful decision from a successful business action. A replicated machine can agree to process a request and then consistently reject it because the seat is occupied. That rejection is a correct execution, not failure of agreement. To evaluate a proposed design, write a successful reservation history, a permitted rejection history, and a failure history that the service promises to survive. Mark what each client knows after every response. This produces concrete obligations for the protocols that follow without assuming that every request must succeed or that unavailable machines can always be bypassed.