---
title: "Impossibility Under Asynchrony: What Consensus Cannot Promise"
description: "With no bound on message delay and one process allowed to fail, no algorithm is guaranteed both to agree and to finish. Real systems live with this by giving up guaranteed termination and leaning on t"
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-09-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 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 algorithm guarantees both agreement and finishing. That clash is the impossibility result, and its model assumes crash failures with 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 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.

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

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

## Practice

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

## Needs first

- [Failure Models and Replication](https://lightmysky.com/learn/computing/failure-models-and-replication-mt_aYK210-NIS)
- [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)

## Opens up

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