<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Consensus on Chen Kai Blog</title><link>https://www.chenk.top/en/tags/consensus/</link><description>Recent content in Consensus on Chen Kai Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sun, 28 Apr 2024 09:00:00 +0000</lastBuildDate><atom:link href="https://www.chenk.top/en/tags/consensus/index.xml" rel="self" type="application/rss+xml"/><item><title>Databases (7): Distributed Transactions — 2PC, Saga, and Why Consensus Is Hard</title><link>https://www.chenk.top/en/databases/07-distributed-transactions/</link><pubDate>Sun, 28 Apr 2024 09:00:00 +0000</pubDate><guid>https://www.chenk.top/en/databases/07-distributed-transactions/</guid><description>&lt;p>Everything we covered about transactions in Article 3 assumed a single database server: one machine, one transaction log, one lock manager. When your data spans multiple machines—through sharding, using microservices with separate databases, or replicating with strong consistency—you face the hardest problem in distributed systems: how do you get multiple machines to agree?&lt;/p>
&lt;hr>
&lt;h2 id="the-distributed-transaction-problem" class="heading-anchor">The Distributed Transaction Problem&lt;a href="#the-distributed-transaction-problem" class="heading-link" aria-label="Permalink to this section" title="Copy link to this section">#&lt;/a>
&lt;/h2>&lt;p>Consider an e-commerce system with separate services for orders and inventory, each with its own database:&lt;/p></description></item></channel></rss>