Two-phase commit protocol

Welcome to the fourth post in the distributed systems series. In the last post, we covered ACID transactions. ACID transactions guarantee

  1. Atomicity: Either all the operation succeed or none
  2. Consistency: System moves from one consistent state to another at the successful completion of a transaction
  3. Isolation: Concurrent transactions do not interfere with each other
  4. Durability: After successful completion of a transaction all changes made by the transaction persist even in the case of a system failure

If the database is running on a single machine then it is comparatively easier to guarantee ACID semantics in comparison to a distributed database. Following are the reasons you would want to run a database in a distributed fashion:

  1. To be fault-tolerant
  2. To handle more reads and writes

Let’s assume our’s is a read intensive application and our single machine database is not able to scale to our demand. One of the solution to scale read is achieved through replication. The most common replication topology is single master and multiple slaves. All the writes go to the master and reads are performed on slaves. Data from master is replicated to the salves synchronously or asynchronously. In this post, we will assume synchronous replication.

Read More »

Issue #16: 10 Reads, A Handcrafted Weekly Newsletters for Humans

Hello All,
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 165 minutes.  This week has stories on writing, remote code execution on Facebook servers, peter principle, Java 11 ZGC, Serverless patterns, PostgreSQL fast column creation, and few more.
Leadership is nature’s way of removing morons from the productive flow. – Dilbert

Read More »