Welcome to the fourth post in the distributed systems series. In the last post, we covered ACID transactions. ACID transactions guarantee
- Atomicity: Either all the operation succeed or none
- Consistency: System moves from one consistent state to another at the successful completion of a transaction
- Isolation: Concurrent transactions do not interfere with each other
- 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:
- To be fault-tolerant
- 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.
Shekhar Gulati 