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.
Read More »
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 190 minutes. This week has stories on performance cost of containerization, how Slack built a scalable service for handling user preferences, productivity, security, shallow reading, ACID transactions, and few more.
Whether you think you can, or you think you can’t – you’re right — Henry Ford
Read More »
Welcome to the third post of distributed system series. So far in this series, we have looked at service discovery and CAP theorem. Before we move along in our distributed system learning journey, I thought it will be useful to refresh our memory with understanding of ACID transactions. ACID transactions are at the heart of relational databases. The knowledge of ACID transactions is useful when building distributed applications.
Understanding ACID transactions
A transaction is a sequence of operations that form a single logical unit of work. These transactions are executed on a shared database system to perform a higher-level function. An example of higher-level function is transferring money from one account to another. Transactions represent a basic unit of change in the database. It either executed in its entirety or not at all.
ACID (Atomicity, Consistency, Isolation, and Durability) refers to a set of properties that a database transaction should guarantee even in the event of errors, power failure, etc. The canonical example of ACID transaction is transfer of funds from one bank account to another. In a single fund transferring transaction, you have to check the account balance, debit one account, and credit another transaction. ACID properties guarantee that either money transfer from one account to other occur correctly and permanently or in case of failure both accounts have the same initial state. It would be unacceptable if one account was debited but the other account was credited.
Database transactions are motivated by two independent requirements:
- Concurrent database access: Multiple clients can access the system at the same time. This is achieved by the Isolation property of ACID transaction.
- Resiliency to system failures: System remains in consistent state in case of a system failure. This is provided by Atomicity, Consistency, and Durability properties of ACID transaction.
Read More »
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 195 minutes. This week newsletter has stories on bullshit web, CAP theorem, slow thinking, productivity, faster JSON parsing with Stanford Sparser, Serverless, Shopify tech stack and few more.
It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away. – Antoine de Saint Exupéry
Read More »
Most of us are building distributed systems. This is a fact. According to Wikipedia, a distributed system is a system whose components are located on different networked computers, which then communicate and coordinate their actions by passing messages to each other. A distributed system could either be a standard three-tier web application or it could be a massive multiplayer online game.
The goal of a distributed system is to solve a problem that can’t be solved on a single machine. A single machine can’t provide enough compute or storage resources required to solve the problem. The user of a distributed system perceives the collection of autonomous machines as a single unit.
The distributed systems are complex as there are several moving parts. You can scale out components to finish the workloads in a reasonable time. Because of numerous moving parts and their different scaling needs it becomes difficult to reason out the characteristics of a distributed applications. CAP theorem can help us.
Read More »
Here are 10 reads I thought were worth sharing this week. The total time to read this newsletter is 130 minutes. This week newsletter has stories on Firebase, how to manage your engineering superheroes, service discover, habits to adopt in your life, how to do full text search with PostgreSQL, being a remote developer, few more.
For every complex problem there is an answer that is clear, simple, and wrong — H. L. Mencken
Read More »