System Design — Transaction Isolation levels

Why do we need to know about isolation levels?
— Have you even thought of what will happen if one transaction reads data that is concurrently modified by another transaction, or when two transactions try to simultaneously modify the same data. Here’s when concurrency issue starts.
— Its hard to debug or test concurrency bugs because you have to match the timing when 2 transaction concurrently modifying the same data and you will never know which 2 transaction caused issue in your system.

Types of isolation levels:
1. Read Uncommitted (Isolation Level 0) — Weak
2. Read Committed (Isolation Level 1) — Weak
3. Repeatable Read (Isolation Level 2) — Intermediate
4. Serializable (Isolation Level 3) — Strong
Note: In simple terms, isolation levels can be categorized as the weakest, intermediate, and strongest.

“Now, let’s dive into each of these isolation levels. I know it’s a lot to learn in this module, don’t you worry I’ve got you all covered.”

1. Read Uncommitted : —
   - This is one of the easiest to understand and interesting. In this level, transactions can see changes made by other transactions even before they are committed.
   - It allows for dirty reads, now you must be wondering about dirty reads.
   It basically means when a transaction reads data that has been modified by other transaction but not yet committed.
   - While read uncommitted provides high concurrency, it sacrifies data consistency. So, this weak level of isolation must be used where you don’t really care about consistency. (which mean you are okay with losing data.)
   Example:
   1. Lets say a transaction A and B is running concurrently.
   2. Transaction A updates value X but has not committed the changes yet.
   3. Transaction B is using read_uncommitted which allow Tb to read the updated value from Ta even tho it’s not yet committed.

Real life example:
Here are some interesting examples where READ_UNCOMMITTED is used:
— Youtube views counter
— Live Counter in Cricket Matches (Hotstar, Streaming Platforms)
— Amazon product inventory management. Now, this might seem counterintuitive because if we use READ_UNCOMMITTED, we have to compromise consistency, and in product inventory management, we need our system to be consistent. I will probably discuss this further later on.

2. Read Committed : —
// TODO