ACID là 4 tính chất giúp transaction trong database đảm bảo dữ liệu đúng đắn và đáng tin cậy: Atomicity, Consistency, Isolation, Durability.

Ví dụ xuyên suốt: chuyển 100k từ A → B.

A: 500k
B: 200k

Transfer 100k

A: 400k
B: 300k

Nếu giữa chừng có lỗi thì không được xảy ra:

A: 400k
B: 200k  ❌ mất 100k

1. Atomicity — Tính nguyên tử

Transaction hoặc thành công toàn bộ, hoặc thất bại toàn bộ.

Transfer gồm:

1. A - 100k
2. B + 100k

Nếu bước 2 fail:

A - 100k
B + 100k ❌

→ Rollback bước 1

Kết quả:

A: 500k
B: 200k

Database làm thế nào?

Thông qua transaction:

BEGIN;
UPDATE accountSET balance= balance-100000
WHERE id='A';
UPDATE accountSET balance= balance+100000
WHERE id='B';
COMMIT;

Nếu lỗi:

ROLLBACK;

⚠️ Atomicity không có nghĩa là...

"Toàn bộ hệ thống rollback."

Nó chủ yếu đảm bảo các operation nằm trong cùng một database transaction.

Ví dụ:

DB Order
   ↓
Payment Service
   ↓
Inventory Service

Không thể đơn giản dùng ROLLBACK của PostgreSQL để rollback transaction ở Payment Service.

→ Đây là lý do distributed transaction thường phải dùng Saga / compensation.

2. Consistency — Tính nhất quán

Transaction phải đưa database từ một trạng thái hợp lệ → một trạng thái hợp lệ khác.

Ví dụ database có constraint:

balance>=0

Trước transaction:

A = 500k
B = 200k

Transfer 100k:

A = 400k
B = 300k

→ Valid.

Nhưng nếu transfer 600k:

A = -100k ❌

Database có thể reject transaction nhờ constraint:

CHECK (balance>=0)

Consistency đến từ đâu?

Không chỉ từ database engine mà còn từ:

• PRIMARY KEY
• FOREIGN KEY
• UNIQUE
• CHECK
• NOT NULL
• application business rules

Order phải có Customer
Stock không được < 0
Email không được duplicate

Điểm dễ nhầm

Consistency trong ACID ≠ Consistency trong CAP

Hai khái niệm có liên quan nhưng không giống nhau.

• ACID Consistency → transaction giữ database ở trạng thái hợp lệ.
• CAP Consistency → mọi node nhìn thấy dữ liệu nhất quán theo mô hình consistency của hệ thống.

3. Isolation — Tính cô lập

Các transaction chạy đồng thời nhưng phải hạn chế việc chúng nhìn thấy trạng thái trung gian của nhau.

Ví dụ:

Transaction A:
A - 100k

Transaction B:
đọc balance A

Nếu A chưa commit mà B đã đọc được:

A = 400k

thì B có thể đang nhìn thấy dữ liệu chưa hoàn tất.

Isolation giải quyết các vấn đề như:

Dirty Read
Non-repeatable Read
Phantom Read

4. Durability — Tính bền vững

Sau khi COMMIT thành công, dữ liệu phải được đảm bảo tồn tại ngay cả khi database/server crash.

Ví dụ:

COMMIT;

Database trả:

SUCCESS

Ngay sau đó server:

💥 CRASH

Khi database restart:

A = 400k
B = 300k

không được quay lại:

A = 500k
B = 200k ❌

Database thường sử dụng cơ chế như:

Transaction
    ↓
WAL / Transaction Log
    ↓
Disk
    ↓
COMMIT

Ví dụ PostgreSQL sử dụng Write-Ahead Logging (WAL).

Tổng hợp

Có thể nhớ:

A → Làm hết hoặc không làm gì
C → Data luôn hợp lệ
I → Transaction không "đụng" nhau sai cách
D → Commit rồi thì không mất