---
title: "Impossibility Under Asynchrony: What Consensus Cannot Promise"
description: "With no bound on message delay and one process allowed to fail, no deterministic algorithm is guaranteed both to agree and to finish. Real systems live with this by giving up guaranteed termination an"
canonical: https://lightmysky.com/learn/computing/impossibility-under-asynchrony-what-consensus-cannot-promise-mt_le54TNOeiR
source: https://lightmysky.com/learn/computing/impossibility-under-asynchrony-what-consensus-cannot-promise-mt_le54TNOeiR.md
retrieved: 2026-11-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Impossibility Under Asynchrony: What Consensus Cannot Promise

With no bound on message delay and one process allowed to fail, no deterministic algorithm is guaranteed both to agree and to finish. Real systems live with this by giving up guaranteed termination and leaning on timeouts, which are a failure detector under another name.

Subject: Computing · Area: Networks & Security · Ages 22 to 23
Page: https://lightmysky.com/learn/computing/impossibility-under-asynchrony-what-consensus-cannot-promise-mt_le54TNOeiR

## Ready when they can

- State the two properties the impossibility result puts in conflict and the model it assumes
- Say which property practical systems relax, and what a timeout is standing in for
- Explain why a slow process and a failed process cannot be told apart in this model

## Lesson: What async consensus cannot promise

With no bound on message delay and one process allowed to crash, no deterministic algorithm guarantees both agreement and finishing. Agreement is the safety property and finishing is the progress property from the consensus topic. That clash is the impossibility result, often called FLP after Fischer, Lynch and Paterson. Its model assumes crash failures and fully asynchronous messages.

**Example.** A process goes silent. It may have crashed, or its messages may just be slow, and nothing in the model tells the two apart. Waiting forever risks never finishing, while deciding without it risks agreeing wrongly.

Practical systems relax guaranteed finishing, also called termination, and lean on timeouts instead. A timeout says no news after some wait counts as failed, which makes it a failure detector under another name. It can wrongly suspect a merely slow process.

State the price precisely: asynchrony plus one crash means agreement and guaranteed finish cannot both hold. Then say which guarantee your system gives up.

*(drawing: With no delay bound, silence leaves two choices, and each has a risk.)*

**Recap.** Async plus one crash forbids promising both agreement and finish, so systems trade finish for timeouts.

*Original instructional content authored for os-taxonomy.*

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Consensus and Why Agreement Is Hard](https://lightmysky.com/learn/computing/consensus-and-why-agreement-is-hard-mt_cF-JiM_xRz)
- [Clocks, Ordering and Happens-Before](https://lightmysky.com/learn/computing/clocks-ordering-and-happens-before-mt_ratia1eb_2)

## Optional connections

- [Failure Models and Replication](https://lightmysky.com/learn/computing/failure-models-and-replication-mt_aYK210-NIS)

## Opens up

- [Raft: Leader Election and Log Replication](https://lightmysky.com/learn/computing/raft-leader-election-and-log-replication-mt_JdHtEJSPSP)