Verteilte Systeme

Worum es geht

The engineering and theory of systems whose parts run on separate machines connected by an unreliable network, where components fail independently and no participant can observe global state. The subject exists because those three conditions break every intuition carried over from single-machine programming: a call can fail in ways that leave the caller unable to tell whether it happened (partial failure), there is no shared clock that orders events (Lamport 1978), and no deterministic protocol can guarantee that independent processes ever agree if even one may crash (Fischer, Lynch and Paterson 1985). Everything else in the field is a disciplined response to those limits: consensus algorithms that trade guaranteed termination for guaranteed safety (Paxos 1998, Raft 2014), replication and quorums that trade coordination for latency, a spectrum of consistency models from linearizability down to eventual consistency, and a well-documented gap between the guarantee a system claims and the one it delivers.

Was im Paket steckt

Kuratiertes Gerüst, das dein Agent vor der Recherche lädt, damit er auf geprüftem Boden startet statt bei null.

• Tier 1: 28
• Tier 2: 7
• Tier 3: 5
• Tier 4: 1

Die Fragen und Behauptungen unten sind wörtlich aus den Paketdateien zitiert. Die Pakete sind durchgehend englisch, weil sie für Agenten geschrieben sind.

Wo das Feld sich uneinig ist

Jede trägt echte Vertreter auf mehr als einer Seite, damit dein Agent nicht still einen Sieger kürt.

• Is the CAP theorem a useful design tool, a misused slogan, or an artefact that should be retired?

  4 benannte Positionen · the theorem is settled and the popular reading is repudiated by both its originator and its provers; whether any successor framing (PACELC, delay sensitivity, HAT) becomes standard is unresolved

• Is understandability a legitimate design criterion for a consensus algorithm, and are Paxos and Raft materially different?

  4 benannte Positionen · Raft won adoption decisively; whether that reflects genuine algorithmic difference or better exposition and packaging remains argued in print

• Should systems default to strong consistency and pay coordination costs, or to weak consistency and export reconciliation to applications?

  4 benannte Positionen · the field has moved from ideological to workload-specific; consensus-backed transactional systems regained ground after 2012 while CRDTs took the collaboration niche, and the defaults question is still argued per system

• Should distributed systems build correctness on synchronised physical clocks?

  4 benannte Positionen · bounded-uncertainty designs are proven in production at Google and increasingly available elsewhere; whether clock-based correctness is prudent for ordinary deployments remains genuinely contested

• Does decomposing an application into networked services solve more problems than it creates?

  4 benannte Positionen · contested, and unusually evidence-poor — the literature is practitioner reports and case studies with strong selection effects, not controlled comparison

Mythen, die das Paket korrigiert

Verbreitete Behauptungen mit der Evidenz, die sie klärt oder begrenzt.

• “The CAP theorem says a distributed system can have only two of consistency, availability and partition tolerance, so every system is either CP or AP and you choose which two you want.”

  debunked-as-stated

  Three separate errors. First, partition tolerance is not a choice: it is an assumption about the network, and networks partition, so a system that does not tolerate partitions simply breaks when one occurs. Second, the tradeoff is only active during a partition — Brewer's own 2012 correction states that partitions are rare, that systems should provide both consistency and availability the rest of the time, and that the actual design work is detecting a partition, entering an explicit partition mode with a restricted operation set, and running compensation on recovery. Third, the theorem's terms are far narrower than the slogan: the proved C is linearizability of a single read-write register, and the proved A is that every request to a non-failed node eventually returns a non-error response with no time bound — so a system that answers every request after ten minutes is CAP-available while being operationally useless, and one that is unavailable for other reasons can still satisfy CAP-availability. Gilbert and Lynch say in their own retrospective that the result is one instance of the older safety-liveness-timing tradition rather than a taxonomy of databases; Abadi's PACELC adds the tradeoff paid on every ordinary request (latency against consistency); and Kleppmann argues the definitions are idiosyncratic enough that CAP should be dropped as a design tool. Nothing here weakens the theorem — it is true and proved. What is false is the shape people carry away from it.

• “Modern messaging systems provide exactly-once delivery.”

  debunked-as-stated

  Exactly-once delivery over an unreliable channel is impossible, and has been known to be since 1975: the sender cannot distinguish a lost message from a lost acknowledgement, so it must either not retry (and risk zero deliveries) or retry (and risk more than one), and adding another acknowledgement only moves the uncertainty one hop. What is achievable is an exactly-once effect, which is a different claim about a different layer: the receiver deduplicates on a message identifier, makes the processing idempotent, or commits the side effect and the record of consumption in a single atomic operation. This is the honest reading of the systems that advertise the phrase — Kafka's idempotent producer and transactions, for example, give exactly-once processing within a read-process-write cycle whose input, output and offsets all live in Kafka, and the guarantee ends at the boundary where a side effect escapes to a system that is not part of that transaction. Sending an email or charging a card cannot be undone by a transaction abort, so at that boundary the application still owns idempotence. The useful question is never "is delivery exactly once" but "what happens when this message arrives twice".

• “Eventual consistency means the data will be wrong, or that writes will be silently lost, so it is only acceptable for things that do not matter.”

  debunked

  Eventual consistency is a convergence guarantee: if updates stop, all replicas converge on the same value. Its genuine weakness is that it bounds nothing about what a read returns now, which is why the useful questions are quantitative — how stale, how often — and why the research answer was to measure it: probabilistically bounded staleness work found production quorum configurations that were consistent within milliseconds in the common case. The data-loss story belongs to conflict resolution, not to the model. Last-write-wins discards concurrent updates and depends on clocks that are not comparable across machines, so it does lose writes; version vectors preserve concurrent versions for the application to merge, as Dynamo's shopping cart does; and conflict-free replicated data types make the merge a mathematical property, so replicas that have received the same set of updates reach the same state in any order, with no coordination and no lost updates. That is strong eventual consistency, and it is what collaborative editors and offline-capable applications run on. The real limits are different and worth teaching in place of the myth: eventual consistency cannot enforce a global invariant such as a non-negative balance or a unique username, and it moves reasoning about concurrency into application code, where it is easy to get wrong.

• “Modern datacenter networks are reliable enough that partitions are a textbook concern; in practice you can design as if the network stays up.”

  debunked

  The measured record says otherwise. Bailis and Kingsbury compiled documented partition and connectivity failures from Amazon, Google, Microsoft, CERN and many operators: flapping links, firmware bugs producing one-way connectivity, misconfigurations, congestion collapse, NIC failures that dropped some traffic and not other traffic, and partitions lasting from seconds to days. Asymmetric and partial partitions — where A can reach B but B cannot reach A, or where two nodes can each reach the client but not each other — are common and are worse than clean splits, because failure detectors disagree about who is alive. A process pause is indistinguishable from a partition to every observer: a long garbage-collection stop, a virtual machine migration or a swapping host produces exactly the symptoms of a partitioned node, which means partitions effectively occur even when the network is perfect. Brewer's 2012 article agrees that partitions are rare — and draws the opposite conclusion from the one this misconception draws: because they are rare, you should optimise for both consistency and availability outside them, and because they are real, you need an explicit plan for what happens during one.

• “Splitting an application into microservices makes it simpler, more scalable and more reliable, and modern frameworks and service meshes handle the distributed-systems concerns for you.”

  debunked

  Decomposition creates distributed-systems problems that did not exist before; it does not remove them. Waldo and colleagues stated the reason in 1994 and it has not changed: latency, memory access, concurrency and partial failure are not implementation details that a transparency layer can hide, so a function call that becomes a network call acquires failure modes with no local equivalent. Concretely, an in-process invariant becomes a distributed one; a database transaction becomes a saga or a two-phase commit with its blocking behaviour; a stack trace becomes correlated logs across services; a retry becomes a duplicate that the callee must be idempotent against; and a slow dependency becomes a source of cascading timeouts and retry storms. Service meshes supply retries, timeouts and circuit breakers, which are mitigations, not solutions — a retry policy applied to a non-idempotent operation makes the system less correct, not more. The originators of the term are among the more honest sources on this: their own article lists distribution, eventual consistency and operational complexity as prices paid, and Fowler's follow-up writing argues for starting with a monolith and for a prerequisite level of operational maturity. The defensible version of the claim is organisational, not technical — service boundaries aligned with team boundaries can buy independent deployability and team autonomy that are worth the distributed costs — and the failure case has a name, the distributed monolith: services that must be deployed together and share a database, paying every cost of distribution and collecting none of the benefits.

Verwandte Themen

• Kryptografie
• Systemdenken