{"id":46474,"date":"2024-02-02T13:03:53","date_gmt":"2024-02-02T12:03:53","guid":{"rendered":"https:\/\/www.inovex.de\/?p=46474"},"modified":"2026-06-12T11:17:46","modified_gmt":"2026-06-12T09:17:46","slug":"distributed-systems-why-does-consensus-matter","status":"publish","type":"post","link":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/","title":{"rendered":"Consensus in Distributed Systems: Why Agreement is Hard"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Distributed systems are hard \u2013 not because individual machines are hard to understand, but because machines can be correct and still disagree about some part of reality.<\/span><\/p>\n<p><!--more--><\/p>\n<p><span style=\"font-weight: 400;\">If multiple machines are responsible for a shared state, they need to make one coherent decision instead of several conflicting ones. They need to agree on who the leader is, which write happened first, whether a lock was acquired, or which configuration is current.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">That problem is called consensus \u2013 it is not a protocol or an implementation detail, it is the foundation that allows distributed systems to behave as if there were one reliable source of truth. Even though the system is built from unreliable parts.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Consensus-based decision making is not originally a computer science idea; people use consensus to let groups reach decisions without relying on a single authority. Both people and machines rely on consensus to move beyond individual viewpoints and coordinate toward outcomes that serve the greater good of the system or community.<\/span><\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_85 counter-hierarchy ez-toc-counter ez-toc-custom ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\"><p class=\"ez-toc-title\" style=\"cursor:inherit\"><\/p>\n<\/div><nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#The-Fundamental-Problem-of-Distributed-Systems\" >The Fundamental Problem of Distributed Systems<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#From-a-Single-etcd-Node-to-a-Consensus-Cluster\" >From a Single etcd Node to a Consensus Cluster<\/a><ul class='ez-toc-list-level-3' ><li class='ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#Simple-but-Fragile\" >Simple but Fragile<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#Process-Resilience\" >Process Resilience<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#Member-and-Leader\" >Member and Leader<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#Consensus\" >Consensus<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-3'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#Quorum\" >Quorum<\/a><\/li><\/ul><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#FLP-Theorem-of-Distributed-Systems\" >FLP Theorem of Distributed Systems<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#Kafka-Another-Place-Where-Consensus-Shows-Up\" >Kafka: Another Place Where Consensus Shows Up<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#Final-Remarks\" >Final Remarks<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"The-Fundamental-Problem-of-Distributed-Systems\"><\/span><b>The Fundamental Problem of Distributed Systems<\/b><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">The hard question is: How can a group of machines make one correct decision when every machine may have only a partial, outdated, or contradictory view of reality?<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Machines do not work perfectly all the time. A message may look lost, but actually arrives later. A leader may look unavailable to a partition of machines due to a network partition, but might still be recognized as a leader to another partition of machines. A node may look failed, but actually be slow. What if multiple machines think they are the leader? What if a machine lies about its own state? All these problems and many more concern the field of consensus.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Thus, to be more precise, the fundamental problem of distributed systems is to design and build reliable systems in the presence of a number of faulty processes and system components.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">But \u201cfaulty\u201c is a broad term. Before we can talk about how distributed systems tolerate faulty processes and components, we need to clarify what can actually go wrong: the difference between faults, errors, and failures.<\/span><\/p>\n<p><strong>Fault<\/strong><span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">A fault is the underlying cause of a problem. It could be a bug, a hardware defect, a software or hardware misconfiguration, a corrupted disk, or a network issue.<\/span><\/p>\n<p><strong>Error<\/strong><span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">An error is the incorrect internal state caused by a fault. At this point, the system has not necessarily failed externally, but some part of its state or assumptions is already incorrect. For example, a node might believe that a healthy peer has failed, or it believes that it is connected to the wrong cluster member, or that its local state diverges from the leader\u2019s state.<\/span><\/p>\n<p><strong>Failure<\/strong><span style=\"font-weight: 400;\"><br \/>\n<\/span><span style=\"font-weight: 400;\">A failure is the externally visible consequence: the system no longer provides the expected service. It might reject valid requests, become unavailable, or violate a consistency guarantee.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">To sum up, a fault is the cause of a problem, an error is the invalid internal state caused by that fault, and a failure is the externally visible deviation from the system\u2019s expected behavior.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"From-a-Single-etcd-Node-to-a-Consensus-Cluster\"><\/span>From a Single etcd Node to a Consensus Cluster<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<h3><span class=\"ez-toc-section\" id=\"Simple-but-Fragile\"><\/span>Simple but Fragile<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">Up to this point, we have discussed consensus mostly in abstract terms. To make the problem more concrete, let\u2019s look at a system that many engineers are familiar with: Kubernetes and its backing store, etcd.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In Kubernetes, etcd acts as the control plane\u2019s source of truth. It contains information about the workload running on the cluster, which nodes are part of the cluster, how services are configured, what secrets and configuration objects exist, and much more information. Basically, etcd is the long-term memory of Kubernetes\u2019 brain.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The Kubernetes API server reads from and writes to etcd whenever the desired or observed state of the cluster changes. It is the place where the control plane records the decisions that define the cluster. But in principle, etcd is just a durable key-value database.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Suppose we run our Kubernetes cluster with a single etcd instance: one process on one machine. This is simple to understand and operate, but it is also fragile because the control plane now depends on the availability of a single machine, disk, process, and network path.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">To improve this setup, our first goal is to increase process resilience: the system\u2019s ability to continue operating when individual processes fail and to recover when failures occur. <\/span><span style=\"font-weight: 400;\">One way to achieve this is to replicate the service across multiple processes instead of relying on a single instance. Replicated processes can be organized in different ways. Two common models are hierarchical groups and flat groups. <\/span><\/p>\n<p><span style=\"font-weight: 400;\">Before we continue our journey from a single etcd process to a resilient etcd cluster, let us clarify a few terms. We have already mentioned hierarchical groups, flat groups, members, and leaders; these concepts will become important once the replicas have to coordinate with each other.<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Process-Resilience\"><\/span>Process Resilience<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">In a hierarchical group, one process acts as the coordinator or leader, while the others follow its decisions. In a flat group, all processes are peers and participate more equally in decision-making.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">etcd\u2019s design goal is to provide a reliable, strongly consistent store for critical system state. Thus, the hierarchical model is especially relevant for etcd because systems relying on etcd require strong consistency. By using a leader, the cluster has a single coordination point of writes, allowing all members to agree on one uniform order of decisions.<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Member-and-Leader\"><\/span>Member and Leader<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">A member is one of the etcd processes that belongs to the cluster. A leader is a specific member that is currently responsible for coordinating decisions. For now, these loose definitions are enough. We will refine them later when we look more closely at specific consensus protocols.<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Consensus\"><\/span>Consensus<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">But to come back to our improvement, replicating the etcd process only improves resilience if the replicas do not share the same failure domain. If all etcd members run on the same machine, a machine failure still takes down the entire cluster. To tolerate machine-level failures, the replicated members must be distributed across different machines.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">And this is where problems start to become bothersome \u2013 once the etcd members run on different machines, they can no longer coordinate through local memory or local process communication. They must communicate over the network, which is an inherently unreliable infrastructure component: messages can be delayed, duplicated, lost, or reordered.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">At the same time, each etcd member now stores its data on a separate disk. That means the cluster no longer has one physical copy of state, but multiple copies that must be kept consistent. Without coordination, those copies could diverge and represent different versions of the cluster state.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Humans have faced a similar problem for a long time: once decisions are made by a group rather than a single authority, the group needs a reliable way to record what was agreed. Leslie Lamport captured this idea in his Paxos allegory, where part-time parliamentarians had to maintain consistent copies of parliamentary records despite absent legislators and unreliable messengers. Without consistency, different members could act on different versions of what the parliament had decided.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This is how Leslie Lamport introduced <strong>Paxos<\/strong>, one of the foundational consensus algorithms in distributed systems. It first appeared as a research report and was later published in 1998 as \u201c<a href=\"https:\/\/lamport.azurewebsites.net\/pubs\/lamport-paxos.pdf\">The Part-Time Parliament<\/a>\u201c.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Although Paxos became one of the most important consensus algorithms, it is also famously difficult to understand and implement correctly. Its full specification leaves room for interpretation, and real-world implementations often differ in the details. Nevertheless, Paxos became the foundation for a family of related protocols, including Multi-Paxos, Cheap Paxos, and Fast Paxos, each optimizing for different assumptions and tradeoffs.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This complexity eventually motivated a different approach: <strong>Raft<\/strong>. In 2014, Diego Ongaro and John Ousterhout developed Raft which was designed with understandability as an explicit goal. Instead of presenting consensus as a set of subtle rules, Raft decomposes the problem into clearer parts: leader election, log replication, and safety guarantees. If you would like to read more about Raft in detail, read this <a href=\"https:\/\/raft.github.io\/raft.pdf\">extended version of the original paper<\/a>.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Raft is a leader-based consensus algorithm. At any point in time, one member acts as the leader, while the other members act as followers. The leader coordinates writes and is responsible for making sure that all committed changes are replicated in the same order.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">When a client wants to change state, the request is handled through the leader. The leader turns the change into an entry in its log and sends that entry to the followers. Once a majority of members has acknowledged the entry, the leader marks it as committed. From that point on, the change is considered durable and can be applied to the system state.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Raft does not just replicate data; it replicates an ordered log of decisions. If every member applies the same committed log entries in the same order, they end up with the same state.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For etcd, this means that Kubernetes control plane changes are not merely copied between nodes. They are ordered, replicated, and committed through Raft, so the etcd cluster can expose one strongly consistent view of cluster state.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">If the leader fails, the followers can elect a new leader, as long as a majority of members is still available.<\/span><\/p>\n<h3><span class=\"ez-toc-section\" id=\"Quorum\"><\/span>Quorum<span class=\"ez-toc-section-end\"><\/span><\/h3>\n<p><span style=\"font-weight: 400;\">The phrase \u201ca majority of members\u201c is important enough to give it a name: a <strong>quorum<\/strong>. In etcd\u2019s Raft-based consensus, a quorum is the minimum number of members that must agree before the cluster can safely make progress.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">For a three-member etcd cluster, the quorum size is two (see figure 1). This means the cluster can tolerate one failed member: if one member goes down, the remaining two can still agree on changes and continue operating. But if only one member remains available, the cluster has lost quorum and must stop accepting writes because it can no longer distinguish a safe decision from a conflicting one.<\/span><\/p>\n<figure style=\"width: 862px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" class=\"\" src=\"https:\/\/www.inovex.de\/wp-content\/uploads\/raft-failure-tolerance.png\" alt=\"We can see a table with 3 columns: cluster size, majority and failure tolerance. This table shows the relation between those 3 variables.\" width=\"862\" height=\"485\" \/><figcaption class=\"wp-caption-text\">Figure 1: Failure tolerance table for quorum-based protocols like Raft<\/figcaption><\/figure>\n<p><span style=\"font-weight: 400;\">This is how the cluster can continue operating even when the individual members fail. Important to note is the fact that etcd clusters are commonly deployed with 3, 5, or 7 members. A three-member cluster can tolerate one failed member, a five-number cluster can tolerate two, and a seven-member cluster can tolerate three. Increasing the number of members improves failure tolerance, because the cluster can lose more machines while still preserving quorum.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">However, more members do not come for free. There is no free lunch. Every write still has to be replicated to enough members to reach quorum. A larger cluster means more network communication, more disk writes, more coordination overhead, and often higher latency. Beyond seven members, the additional failure tolerance is usually not worth the performance and operational cost.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">A common source of confusion that we want to mention is that quorum is based on the configured cluster size, not on the number of currently healthy members. A five-member cluster requires 3 members for quorum, so it can tolerate 2 failures. If 2 members fail, the remaining 3 members are not treated as a new three-member cluster with a quorum of 2.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">The reason it works in this way is quorum intersection: any two majorities in the same cluster must overlap in at least one member. Two majorities means two different groups of nodes that are each large enough to form quorum. This overlap prevents two independent groups of members from safely committing conflicting decisions. This idea is older than etcd and Raft. David K. Gifford\u2019s 1979 paper \u201c<a href=\"https:\/\/dl.acm.org\/doi\/pdf\/10.1145\/800215.806583\">Weighted Voting for Replicated Data<\/a>\u201c is a useful reference for readers who want to understand the deeper reasoning behind quorum systems.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">etcd shows why consensus is necessary in practice: once critical control-plane state is replicated across multiple machines, the replicas must not merely store copies, but agree on one ordered history of changes. Raft, leaders, and quorums are the mechanisms that let etcd survive individual failures while still protecting Kubernetes from conflicting sources of truth.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">It is important to note that Raft, and therefore etcd, assumes crash faults, not Byzantine faults. In other words, members may crash, restart, become unreachable, but they are not expected to lie, or send conflicting messages intentionally. Handling Byzantine behavior requires different consensus protocols and usually comes with significantly higher complexity and cost.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"FLP-Theorem-of-Distributed-Systems\"><\/span><b>FLP Theorem of Distributed Systems<\/b><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">So consensus works \u2013 but only under certain assumptions. In 1985, Michael Fischer, Nany Lynch, and Michael Paterson described a model of distributed computation that showed a surprising limit: in a completely asynchronous system, no deterministic consensus protocol can guarantee progress if even a single process may crash.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This result became known as the FLP impossibility theorem. It does not mean that consensus is useless or impossible in practice. It means that consensus protocols depend on assumptions about the system they run in. For example, assumptions about failure detection, timing, retries, or leader election.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">In practice, Raft uses timeouts, heartbeats, leader election, and majority quorums. If followers stop receiving heartbeats from the leader, they eventually assume that the leader may have failed and start a new election.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This means Raft can make progress when the network eventually behaves well enough for messages to be delivered within a reasonable time. Let us be pessimistic and assume the network becomes permanently partitioned; Raft preserves safety by refusing to commit new writes rather than risking conflicting decisions.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"Kafka-Another-Place-Where-Consensus-Shows-Up\"><\/span><b>Kafka: Another Place Where Consensus Shows Up<\/b><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Kafka is usually known as a distributed log for application data, but the Kafka cluster itself has also critical metadata: brokers, topics, and partition leaders.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Older Kafka deployments used ZooKeeper to coordinate this metadata. ZooKeeper is a dedicated cluster of members which uses its own consensus protocol, Zab, to keep its replicated state consistent.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Newer Kafka versions move this responsibility into Kafka itself with KRaft, Kafka\u2019s Raft-based metadata quorum. For more details, have a look at <a href=\"https:\/\/cwiki.apache.org\/confluence\/display\/KAFKA\/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum\">KIP 500<\/a>.<\/span><\/p>\n<h2><span class=\"ez-toc-section\" id=\"Final-Remarks\"><\/span><b>Final Remarks<\/b><span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p><span style=\"font-weight: 400;\">Consensus is not an abstract problem reserved for distributed-systems papers. It appears whenever multiple machines must act as one reliable system while failures, delays, and partitions are still possible.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">This is why systems like Kubernetes, Kafka, and many databases rely on consensus somewhere in their chain.\u00a0<\/span><\/p>\n<p><span style=\"font-weight: 400;\">But consensus is not free. It adds coordination overhead, depends on the majority quorum, and may sacrifice availability when the system cannot make a safe decision. That is the price of preserving correctness.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">It does not hurt to know at least a little about consensus because much of our modern world relies on distributed systems. Every time we use cloud platforms, databases, messaging systems, or large-scale online platforms, we depend on machines agreeing with each other behind the scenes.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">I hope you found this article useful! See you in the next one!<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Distributed systems are hard \u2013 not because individual machines are hard to understand, but because machines can be correct and still disagree about some part of reality.<\/p>\n","protected":false},"author":318,"featured_media":51453,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"ep_exclude_from_search":false,"footnotes":""},"tags":[510,71,377,1033],"service":[420,414,925],"coauthors":[{"id":318,"display_name":"Raphael Skuza","user_nicename":"rskuza"}],"class_list":["post-46474","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-apps-2","tag-cloud","tag-development","tag-kafka","service-apps","service-cloud","service-software-craftsmanship"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.8 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Consensus in Distributed Systems: Why Agreement is Hard - inovex GmbH<\/title>\n<meta name=\"description\" content=\"If you want to know what consensus has to do with distributed systems and where it is used, then this blog article is the right place to start.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Consensus in Distributed Systems: Why Agreement is Hard - inovex GmbH\" \/>\n<meta property=\"og:description\" content=\"If you want to know what consensus has to do with distributed systems and where it is used, then this blog article is the right place to start.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/\" \/>\n<meta property=\"og:site_name\" content=\"inovex GmbH\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/inovexde\" \/>\n<meta property=\"article:published_time\" content=\"2024-02-02T12:03:53+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-06-12T09:17:46+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/Blogheader-Distributed-Systems2.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1500\" \/>\n\t<meta property=\"og:image:height\" content=\"880\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Raphael Skuza\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:image\" content=\"https:\/\/www.inovex.de\/wp-content\/uploads\/Blogheader-Distributed-Systems2-1024x601.png\" \/>\n<meta name=\"twitter:creator\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:site\" content=\"@inovexgmbh\" \/>\n<meta name=\"twitter:label1\" content=\"Verfasst von\" \/>\n\t<meta name=\"twitter:data1\" content=\"Raphael Skuza\" \/>\n\t<meta name=\"twitter:label2\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data2\" content=\"12\u00a0Minuten\" \/>\n\t<meta name=\"twitter:label3\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data3\" content=\"Raphael Skuza\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/\"},\"author\":{\"name\":\"Raphael Skuza\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/126d1a5e3c6b844fa0d4708df41e9cfb\"},\"headline\":\"Consensus in Distributed Systems: Why Agreement is Hard\",\"datePublished\":\"2024-02-02T12:03:53+00:00\",\"dateModified\":\"2026-06-12T09:17:46+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/\"},\"wordCount\":2449,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/Blogheader-Distributed-Systems2.png\",\"keywords\":[\"Apps\",\"Cloud\",\"Development\",\"Kafka\"],\"articleSection\":[\"English Content\",\"Infrastructure\"],\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/\",\"name\":\"Consensus in Distributed Systems: Why Agreement is Hard - inovex GmbH\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/Blogheader-Distributed-Systems2.png\",\"datePublished\":\"2024-02-02T12:03:53+00:00\",\"dateModified\":\"2026-06-12T09:17:46+00:00\",\"description\":\"If you want to know what consensus has to do with distributed systems and where it is used, then this blog article is the right place to start.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/Blogheader-Distributed-Systems2.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/Blogheader-Distributed-Systems2.png\",\"width\":1500,\"height\":880,\"caption\":\"Grafische Darstellung eines verteilten Systems, das mehrere Server zeigt, die durch Linien mit verschiedenen Benutzern und Ger\u00e4ten verbunden sind. Zu sehen sind Personen, die an Computern arbeiten, sowie Symbole f\u00fcr Datenverarbeitung und Netzwerktechnologie.\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/distributed-systems-why-does-consensus-matter\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Consensus in Distributed Systems: Why Agreement is Hard\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#website\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"name\":\"inovex GmbH\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#organization\",\"name\":\"inovex GmbH\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/2021\\\/03\\\/inovex-logo-16-9-1.png\",\"width\":1921,\"height\":1081,\"caption\":\"inovex GmbH\"},\"image\":{\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/logo\\\/image\\\/\"},\"sameAs\":[\"https:\\\/\\\/www.facebook.com\\\/inovexde\",\"https:\\\/\\\/x.com\\\/inovexgmbh\",\"https:\\\/\\\/www.instagram.com\\\/inovexlife\\\/\",\"https:\\\/\\\/www.linkedin.com\\\/company\\\/inovex\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UC7r66GT14hROB_RQsQBAQUQ\"]},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/#\\\/schema\\\/person\\\/126d1a5e3c6b844fa0d4708df41e9cfb\",\"name\":\"Raphael Skuza\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/cropped-Raphael-Skuza-Profilbild-96x96.jpga7fa52311aba9815836e166521178831\",\"url\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/cropped-Raphael-Skuza-Profilbild-96x96.jpg\",\"contentUrl\":\"https:\\\/\\\/www.inovex.de\\\/wp-content\\\/uploads\\\/cropped-Raphael-Skuza-Profilbild-96x96.jpg\",\"caption\":\"Raphael Skuza\"},\"sameAs\":[\"https:\\\/\\\/de.linkedin.com\\\/in\\\/raphael-skuza\"],\"url\":\"https:\\\/\\\/www.inovex.de\\\/de\\\/blog\\\/author\\\/rskuza\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Consensus in Distributed Systems: Why Agreement is Hard - inovex GmbH","description":"If you want to know what consensus has to do with distributed systems and where it is used, then this blog article is the right place to start.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/","og_locale":"de_DE","og_type":"article","og_title":"Consensus in Distributed Systems: Why Agreement is Hard - inovex GmbH","og_description":"If you want to know what consensus has to do with distributed systems and where it is used, then this blog article is the right place to start.","og_url":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/","og_site_name":"inovex GmbH","article_publisher":"https:\/\/www.facebook.com\/inovexde","article_published_time":"2024-02-02T12:03:53+00:00","article_modified_time":"2026-06-12T09:17:46+00:00","og_image":[{"width":1500,"height":880,"url":"https:\/\/www.inovex.de\/wp-content\/uploads\/Blogheader-Distributed-Systems2.png","type":"image\/png"}],"author":"Raphael Skuza","twitter_card":"summary_large_image","twitter_image":"https:\/\/www.inovex.de\/wp-content\/uploads\/Blogheader-Distributed-Systems2-1024x601.png","twitter_creator":"@inovexgmbh","twitter_site":"@inovexgmbh","twitter_misc":{"Verfasst von":"Raphael Skuza","Gesch\u00e4tzte Lesezeit":"12\u00a0Minuten","Written by":"Raphael Skuza"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#article","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/"},"author":{"name":"Raphael Skuza","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/126d1a5e3c6b844fa0d4708df41e9cfb"},"headline":"Consensus in Distributed Systems: Why Agreement is Hard","datePublished":"2024-02-02T12:03:53+00:00","dateModified":"2026-06-12T09:17:46+00:00","mainEntityOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/"},"wordCount":2449,"commentCount":0,"publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/Blogheader-Distributed-Systems2.png","keywords":["Apps","Cloud","Development","Kafka"],"articleSection":["English Content","Infrastructure"],"inLanguage":"de","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/","url":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/","name":"Consensus in Distributed Systems: Why Agreement is Hard - inovex GmbH","isPartOf":{"@id":"https:\/\/www.inovex.de\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#primaryimage"},"image":{"@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#primaryimage"},"thumbnailUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/Blogheader-Distributed-Systems2.png","datePublished":"2024-02-02T12:03:53+00:00","dateModified":"2026-06-12T09:17:46+00:00","description":"If you want to know what consensus has to do with distributed systems and where it is used, then this blog article is the right place to start.","breadcrumb":{"@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#primaryimage","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/Blogheader-Distributed-Systems2.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/Blogheader-Distributed-Systems2.png","width":1500,"height":880,"caption":"Grafische Darstellung eines verteilten Systems, das mehrere Server zeigt, die durch Linien mit verschiedenen Benutzern und Ger\u00e4ten verbunden sind. Zu sehen sind Personen, die an Computern arbeiten, sowie Symbole f\u00fcr Datenverarbeitung und Netzwerktechnologie."},{"@type":"BreadcrumbList","@id":"https:\/\/www.inovex.de\/de\/blog\/distributed-systems-why-does-consensus-matter\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.inovex.de\/de\/"},{"@type":"ListItem","position":2,"name":"Consensus in Distributed Systems: Why Agreement is Hard"}]},{"@type":"WebSite","@id":"https:\/\/www.inovex.de\/de\/#website","url":"https:\/\/www.inovex.de\/de\/","name":"inovex GmbH","description":"","publisher":{"@id":"https:\/\/www.inovex.de\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.inovex.de\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":"Organization","@id":"https:\/\/www.inovex.de\/de\/#organization","name":"inovex GmbH","url":"https:\/\/www.inovex.de\/de\/","logo":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/2021\/03\/inovex-logo-16-9-1.png","width":1921,"height":1081,"caption":"inovex GmbH"},"image":{"@id":"https:\/\/www.inovex.de\/de\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/inovexde","https:\/\/x.com\/inovexgmbh","https:\/\/www.instagram.com\/inovexlife\/","https:\/\/www.linkedin.com\/company\/inovex","https:\/\/www.youtube.com\/channel\/UC7r66GT14hROB_RQsQBAQUQ"]},{"@type":"Person","@id":"https:\/\/www.inovex.de\/de\/#\/schema\/person\/126d1a5e3c6b844fa0d4708df41e9cfb","name":"Raphael Skuza","image":{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.inovex.de\/wp-content\/uploads\/cropped-Raphael-Skuza-Profilbild-96x96.jpga7fa52311aba9815836e166521178831","url":"https:\/\/www.inovex.de\/wp-content\/uploads\/cropped-Raphael-Skuza-Profilbild-96x96.jpg","contentUrl":"https:\/\/www.inovex.de\/wp-content\/uploads\/cropped-Raphael-Skuza-Profilbild-96x96.jpg","caption":"Raphael Skuza"},"sameAs":["https:\/\/de.linkedin.com\/in\/raphael-skuza"],"url":"https:\/\/www.inovex.de\/de\/blog\/author\/rskuza\/"}]}},"_links":{"self":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/46474","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/users\/318"}],"replies":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/comments?post=46474"}],"version-history":[{"count":5,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/46474\/revisions"}],"predecessor-version":[{"id":67930,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/posts\/46474\/revisions\/67930"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media\/51453"}],"wp:attachment":[{"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/media?parent=46474"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/tags?post=46474"},{"taxonomy":"service","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/service?post=46474"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.inovex.de\/de\/wp-json\/wp\/v2\/coauthors?post=46474"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}