<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[The CAP Dilemma: Pick Your Poison]]></title><description><![CDATA[The CAP Dilemma: Pick Your Poison]]></description><link>https://the-cap-dilemma-pick-your-poison.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Tue, 10 Nov 2026 14:44:32 GMT</lastBuildDate><atom:link href="https://the-cap-dilemma-pick-your-poison.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[The CAP Dilemma: Pick Your Poison]]></title><description><![CDATA[Authored by, Krish Dhumal (Student, Computer Department, Vidyalankar Institute of Technology) Aniruddha Yeole (Student, Computer Department, Vidyalankar…]]></description><link>https://the-cap-dilemma-pick-your-poison.hashnode.dev/the-cap-dilemma-pick-your-poison</link><guid isPermaLink="true">https://the-cap-dilemma-pick-your-poison.hashnode.dev/the-cap-dilemma-pick-your-poison</guid><category><![CDATA[CAP-Theorem]]></category><category><![CDATA[CAP]]></category><dc:creator><![CDATA[KRISH]]></dc:creator><pubDate>Wed, 01 Oct 2025 06:52:26 GMT</pubDate><enclosure url="https://cdn.hashnode.com/res/hashnode/image/upload/v1759301420725/ae4665b1-9880-45b5-9cd3-976438ca3212.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p><em>Authored by,</em></p>
<p><em>Krish Dhumal (Student, Computer Department, Vidyalankar Institute of Technology)</em></p>
<p><em>Aniruddha Yeole (Student, Computer Department, Vidyalankar Institute of Technology)</em></p>
<p><em>Aryan Kasar (Student, Computer Department, Vidyalankar Institute of Technology)</em></p>
<p><em>Rohan Khadye (Student, Computer Department, Vidyalankar Institute of Technology)</em></p>
<p><em>Under guidance of,</em></p>
<p><em>Dr. Prakash Parmar (Faculty, Computer Department, Vidyalankar Institute of Technology)</em></p>
<p><em>Dr. Amit K. Nerurkar (Faculty, Computer Department, Vidyalankar Institute of Technology)</em></p>
<p>CAP Theorem: The Impossible Choice That Powers the Internet Have you ever heard the project management mantra: "Fast, cheap, or good: pick two"? This principle states that you can't have all three; you're forced to make a trade-off. In the world of distributed systems—the backbone of modern applications like Google, Netflix, and Amazon—a similar, fundamental law exists. It's called the CAP Theorem.</p>
<p>First conjectured by computer scientist Eric Brewer in 2000 [1], the theorem states that any distributed data store can only provide two of the following three guarantees at the same time: Consistency Availability Partition Tolerance This concept was formally proven by Seth Gilbert and Nancy Lynch of MIT in 2002 [2]. Understanding this theorem is key to understanding how the internet works at scale.</p>
<p>The Three Guarantees: C, A, and P To grasp the theorem, we first need to understand its components.</p>
<ol>
<li><p>Consistency (C) Consistency guarantees that every client sees the same, most up-to-date data. Think of a bank account: after you make a deposit, any check of your balance, from any device, must show that new amount [3].</p>
</li>
<li><p>Availability (A) Availability ensures that the system is always responsive, even if the data isn't the absolute latest version. For example, a social media feed prioritizes showing you content over guaranteeing you see a "like" count update the exact millisecond it happens [2].</p>
</li>
<li><p>Partition Tolerance (P) Partition Tolerance is the ability to keep working even when network failures break communication between servers. In any large-scale system, network outages are inevitable, so this guarantee is non-negotiable [4].</p>
</li>
</ol>
<p>The "Pick Two" Dilemma Since network partitions (P) are unavoidable in real-world distributed systems, the theorem forces a crucial trade-off during a failure: you must choose between Consistency and Availability [4].</p>
<p>Fig-1:CAP theorem</p>
<p><img src="https://cdn.hashnode.com/res/hashnode/image/upload/v1759299903059/4856f3e3-8d9d-411e-b002-39f26faa134b.png" alt /></p>
<ul>
<li><p><strong>Image source:</strong> <a target="_blank" href="https://stackoverflow.com/"><strong>Stack Overflow</strong></a> <a target="_blank" href="https://stackoverflow.com/"><strong>(licensed und</strong></a><strong>er CC BY-SA 4.0</strong>)</p>
</li>
<li><p><strong>CP: Consistency over Availability</strong><br />  A CP system prioritizes data correctness. During a partition, it might return an error or time out rather than serve potentially stale data. This is essential for systems like payment gateways, where accuracy is paramount [2].</p>
</li>
<li><p><strong>AP: Availability over Consistency</strong><br />  An AP system prioritizes responsiveness. During a partition, it will respond with the best data it has, even if it's not the most recent. This leads to "eventual consistency" and is used by systems like Amazon's DynamoDB, where being online is more critical than instant data sync [5].</p>
</li>
<li><p><strong>What about CA?</strong><br />  CA systems (Consistent and Available) only exist on a single server where network partitions aren't a concern. They aren't a practical model for large-scale distributed applications [3].</p>
</li>
<li><p><strong>Conclusion: It's a Trade-off, Not a Final Verdict</strong><br />  The CAP theorem isn't a rigid rule but a guide to understanding trade-offs. As Eric Brewer clarified, the goal isn't just to "pick two," but to intelligently manage these choices when network failures occur [4]. The balance between perfect data (Consistency) and constant uptime (Availability) is the fundamental decision that shapes how all modern, large-scale applications are built.</p>
</li>
</ul>
<h2 id="heading-references">References :</h2>
<p><strong>[1] Brewer, E. (2000). "Towards Robust Distributed Systems." Keynote speech at the Symposium on Principles of Distributed Computing (PODC).</strong></p>
<p><strong>[2] Gilbert, S., &amp; Lynch, N. (2002). "Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services." ACM SIGACT News, 33(2), 51-59.</strong></p>
<p><strong>[3] Kleppmann, M. (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O'Reilly Media.</strong></p>
<p><strong>[4] Brewer, E. (2012). "CAP Twelve Years Later: How the 'Rules' Have Changed." Computer, 45(2), 23-29.</strong></p>
<p><strong>[5] DeCandia, G., et al. (2007). "Dynamo: Amazon's Highly Available Key-value Store." Proceedings of the Twenty-first ACM SIGOPS Symposium on Operating Systems Principles.</strong></p>
<h3 id="heading-image-credits">Image Credits</h3>
<ul>
<li>Image(Fig-1) taken from <a target="_blank" href="https://stackoverflow.com/">Stack Overflow</a> (licensed under CC BY-SA 4.0)</li>
</ul>
]]></content:encoded></item></channel></rss>