Towards Robust Distributed Systems.

Brewer, E. A. (2000). Towards Robust Distributed Systems. ACM.

Type

Conference paper

Intellectual base

Primary research

Year

2000

DOI

10.1145/343477.343502

DOI registrant

Association for Computing Machinery

Link

https://doi.org/10.1145/343477.343502

Cited from

computer_science, economics_finance, logistics_supply_chain, mathematics, sociology_anthropology, synthesized, systems_cybernetics

Cited by

10 citations across 10 artifacts.

Each citation links to the sentence it supports in the citing article.

Primes

• Bottleneck

  • This sourceIn Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (PODC). ACM. Origin of the CAP conjecture. Biblio reference.

• Caching
  • The coherence / consistency model (strong, eventual, or weak) determining when cached copies are invalidated or updated
• Concurrency

  • This sourceKeynote, Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (PODC '00). ACM, 2000. The keynote introducing the CAP trade-off (consistency, availability, partition tolerance). Tier C — cited in the Notes prose ('the CAP theorem (Brewer 2000)') but NOT via any [^ref-6c8c313858a7] footnote marker in the body. Real and correctly attributed. (Defined three times in the source's References section — duplicate entries; see flag.)

• Idempotence
  • The reach is broad enough that the structural property holds across all of mathematics, computer science, infrastructure engineering, security, and ordinary control systems with the same diagnostic skeleton, a unification Brewer (2000) signals in his CAP-theorem framing of consistency-availability tradeoffs.

    This sourceKeynote, ACM Symposium on Principles of Distributed Computing. Formalization of CAP theorem (Consistency, Availability, Partition tolerance); showed that distributed systems cannot simultaneously guarantee all three. CAP theorem formal constraint on distributed systems.

    Supported in partVerified against the publisher's abstract

    Brewer's keynote abstract addresses fault models, high availability, graceful degradation and data consistency in distributed systems; it states no CAP impossibility result and no unification beyond distributed systems.

    “These issues include the fault model, high availability, graceful degradation, data consistency, evolution, composition, and autonomy.”

    Read by an automated reader; not a human review. How support was checked

• Inconsistent Shared Model
  • In distributed computing, split-brain failures (two leaders each authoritative after a partition) and eventual-consistency anomalies (two replicas reading and writing divergent values until reconciliation) are exactly this pattern, and the CAP-theorem trade-off characterises how a system handles it when a partition heals.

    This sourceStates the CAP conjecture — a partitioned system must trade consistency against availability — characterizing how a distributed system handles divergent replicas when a partition heals.

• Role Conflict
  • Analogs: a code module satisfying interfaces of incompatible consumers; a database schema serving transactional and analytical workloads with opposite access patterns; a municipal zone serving residential, commercial, and transit demands with incompatible specifications

    This sourceKeynote, ACM Symposium on Principles of Distributed Computing. Formalization of CAP theorem (Consistency, Availability, Partition tolerance); showed that distributed systems cannot simultaneously guarantee all three. CAP theorem formal constraint on distributed systems.

• Scalability
  • The recognition of fundamental limits: serial fractions, coordination overhead, consistency constraints, and hardware ceilings

    This sourceACM. Formalization of CAP theorem (Consistency, Availability, Partition tolerance); showed that distributed systems cannot simultaneously guarantee all three.

    Supported in partVerified against the publisher's abstract

    Brewer's keynote abstract names data consistency among the issues distributed systems face, covering only the consistency element of this four-part list of limits.

    “These issues include the fault model, high availability, graceful degradation, data consistency, evolution, composition, and autonomy.”

    Read by an automated reader; not a human review. How support was checked

• Trade-offs
  • - Computer science and information systems
• Transaction
  • For distributed transactions, the reasoning must also consider CAP, coordination cost, and partial-failure handling

    This sourceKeynote, ACM Symposium on Principles of Distributed Computing. Formalization of CAP theorem (Consistency, Availability, Partition tolerance); showed that distributed systems cannot simultaneously guarantee all three. CAP theorem formal constraint on distributed systems.

• Trilemma
  • In distributed systems, the CAP theorem holds that consistency, availability, and partition tolerance cannot all be guaranteed under partition, and designs cluster into CP, AP, and (in non-partitioned modes) CA-like configurations.

    This sourceStates the CAP conjecture — a distributed system cannot simultaneously guarantee consistency, availability, and partition tolerance.

Verification

Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.

Does it back the claim? Read against the text for 2 of 10 citations: 2 supported in part. Each verdict is shown under its citation below, with what in the work backs the sentence.

Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.

See how references were verified.

Links previously used in the corpus

Before the registry existed this work was also linked 1 other way.

• https://dl.acm.org/doi/10.1145/343477.343502 ×3

Registry ID ref:6c8c313858a7 · see in the full table