Database Scaling: Relational vs NoSQL

┌─────────────────────────────────────────────────────────────┐
│                    VERTICAL SCALING                         │
│                                                             │
│   Trước:          Sau:                                      │
│   ┌──────┐        ┌──────────────┐                          │
│   │Server│   →    │  BIG Server  │  (Thêm CPU, RAM, SSD)    │
│   │ 4 CPU│        │  32 CPU      │                          │
│   │ 8 GB │        │  128 GB      │                          │
│   └──────┘        └──────────────┘                          │
│                                                             │
│   → Có giới hạn vật lý (không thể tăng mãi)                 │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│                   HORIZONTAL SCALING                        │
│                                                             │
│   Trước:          Sau:                                      │
│   ┌──────┐        ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐       │
│   │Server│   →    │Server│ │Server│ │Server│ │Server│       │
│   │ 4 CPU│        │ 4 CPU│ │ 4 CPU│ │ 4 CPU│ │ 4 CPU│       │
│   └──────┘        └──────┘ └──────┘ └──────┘ └──────┘       │
│                                                             │
│   → Gần như không giới hạn (thêm server thoải mái)          │
└─────────────────────────────────────────────────────────────┘

Ban đầu: 100 users → Server: 2 CPU, 4 GB RAM    → $50/tháng
Tăng:    1,000 users → Server: 8 CPU, 32 GB RAM  → $400/tháng
Tăng:    10,000 users → Server: 32 CPU, 128 GB    → $3,000/tháng
Tăng:    100,000 users → Server: 64 CPU, 512 GB   → $10,000/tháng
Tăng:    1,000,000 users → ??? KHÔNG THỂ TĂNG NỮA! (đã max phần cứng)

Ban đầu: 100 users → 1 Server (4 CPU, 8 GB)      → $100/tháng
Tăng:    1,000 users → 3 Servers                   → $300/tháng
Tăng:    10,000 users → 10 Servers                  → $1,000/tháng
Tăng:    100,000 users → 50 Servers                 → $5,000/tháng
Tăng:    1,000,000 users → 200 Servers              → $20,000/tháng
Tăng:    10,000,000 users → 500 Servers             → $50,000/tháng
          → VẪN CÒN CÓ THỂ TĂNG TIẾP!

┌──────────────────────────────────────────────────────────────────┐
│                       REPLICATION                                │
│          "Photocopy" — mỗi server có BẢN SAO GIỐNG HỆT           │
│                                                                  │
│   Server 1 (Primary)    Server 2 (Replica)   Server 3 (Replica)  │
│   ┌──────────────┐      ┌──────────────┐     ┌──────────────┐    │
│   │ User A       │      │ User A       │     │ User A       │    │
│   │ User B       │ ───→ │ User B       │ ──→ │ User B       │    │
│   │ User C       │      │ User C       │     │ User C       │    │
│   │ User D       │      │ User D       │     │ User D       │    │
│   └──────────────┘      └──────────────┘     └──────────────┘    │
│                                                                  │
│   → 3 servers đều có CÙNG DỮ LIỆU (A, B, C, D)                   │
│   → WRITE chỉ vào Primary, sau đó sync sang Replicas             │
└──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│                        SHARDING                                  │
│          "Chia bánh" — mỗi server giữ 1 PHẦN dữ liệu             │
│                                                                  │
│   Shard 1               Shard 2              Shard 3             │
│   ┌──────────────┐      ┌──────────────┐     ┌──────────────┐    │
│   │ User A       │      │ User C       │     │ User E       │    │
│   │ User B       │      │ User D       │     │ User F       │    │
│   └──────────────┘      └──────────────┘     └──────────────┘    │
│                                                                  │
│   → Mỗi server có DỮ LIỆU KHÁC NHAU                              │
│   → Mỗi shard xử lý cả READ + WRITE cho phần data của mình       │
└──────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────┐
│          SHARDING + REPLICATION (thực tế production)             │
│                                                                  │
│   Shard 1                          Shard 2                       │
│   ┌─────────────┐                  ┌─────────────┐               │
│   │ Primary     │                  │ Primary     │               │
│   │ User A, B   │                  │ User C, D   │               │
│   └──┬──────┬───┘                  └──┬──────┬───┘               │
│      │      │                        │       │                   │
│      ▼      ▼                        ▼      ▼                    │
│   ┌──────┐┌──────┐               ┌──────┐┌──────┐                │
│   │Rep 1 ││Rep 2 │               │Rep 1 ││Rep 2 │                │
│   │A, B  ││A, B  │               │C, D  ││C, D  │                │
│   └──────┘└──────┘               └──────┘└──────┘                │
│                                                                  │
│   Sharding → chia data ra nhiều phần (scale write + storage)     │
│   Replication → sao chép MỖI shard (HA + scale read)             │
└──────────────────────────────────────────────────────────────────┘

"Relational DB khó scale horizontally"

                Replication              Sharding
SQL (RDS):      ✅ Làm được (replicas)   ❌ Rất khó (JOIN, ACID, FK)
NoSQL (Dynamo): ✅ Làm được              ✅ Tự động, dễ dàng

→ Cả hai đều replication được
→ Nhưng SHARDING mới là thứ khó
→ Sharding mới scale được WRITE → đây là "horizontal scaling thực sự"

-- Bảng Users
CREATE TABLE users (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100)
);

-- Bảng Products
CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    price DECIMAL(10,2)
);

-- Bảng Orders
CREATE TABLE orders (
    id INT PRIMARY KEY,
    user_id INT REFERENCES users(id),      -- FK → users
    product_id INT REFERENCES products(id), -- FK → products
    quantity INT,
    order_date DATE
);

SELECT u.name, p.name AS product, o.quantity, o.order_date
FROM orders o
JOIN users u ON o.user_id = u.id          -- JOIN bảng users
JOIN products p ON o.product_id = p.id    -- JOIN bảng products
WHERE o.order_date > '2024-01-01';

┌─────────────────────────────────────────────────────────────────────┐
│                    DỮ LIỆU BỊ CHIA RA 3 SERVERS                     │
│                                                                     │
│   Server 1           Server 2           Server 3                    │
│   ┌──────────┐       ┌──────────┐       ┌──────────┐                │
│   │ users    │       │ products │       │ orders   │                │
│   │ id=1..100│       │ id=1..500│       │ id=1..1M │                │
│   └──────────┘       └──────────┘       └──────────┘                │
│                                                                     │
│   Query: SELECT u.name, p.name FROM orders o                        │
│          JOIN users u ON o.user_id = u.id                           │
│          JOIN products p ON o.product_id = p.id                     │
│                                                                     │
│   → Server 3 có orders, nhưng cần dữ liệu từ Server 1 (users)       │
│     VÀ Server 2 (products)                                          │
│   → Phải gửi request qua NETWORK giữa các servers                   │
│   → RẤT CHẬM so với truy cập dữ liệu local                          │
│   → Càng nhiều JOINs → càng nhiều network calls → càng chậm         │
└─────────────────────────────────────────────────────────────────────┘

-- Transaction: Chuyển 1,000,000 VND từ A sang B
BEGIN TRANSACTION;

UPDATE accounts SET balance = balance - 1000000 WHERE user_id = 'A';
-- Kiểm tra: balance của A >= 0 (constraint)

UPDATE accounts SET balance = balance + 1000000 WHERE user_id = 'B';

COMMIT;
-- Nếu bất kỳ bước nào lỗi → ROLLBACK toàn bộ

┌─────────────────────────────────────────────────────────────────────┐
│          TRANSACTION CHUYỂN TIỀN GIỮA 2 SERVERS                     │
│                                                                     │
│   Server 1 (có tài khoản A)    Server 2 (có tài khoản B)            │
│   ┌──────────────────┐         ┌──────────────────┐                 │
│   │ A: 5,000,000 VND │         │ B: 2,000,000 VND │                 │
│   └──────────────────┘         └──────────────────┘                 │
│                                                                     │
│   Bước 1: Trừ tiền A trên Server 1  ✅                              │
│   Bước 2: Cộng tiền B trên Server 2  ❌ (Server 2 bị lỗi!)          │
│                                                                     │
│   → Phải ROLLBACK bước 1 trên Server 1                              │
│   → Cần "2-Phase Commit" protocol để đồng bộ                        │
│   → Rất chậm, phức tạp, dễ deadlock                                 │
│   → Nếu network bị đứt giữa 2 servers → DỮ LIỆU INCONSISTENT!       │
└─────────────────────────────────────────────────────────────────────┘

-- Foreign Key: order.user_id PHẢI tồn tại trong bảng users
INSERT INTO orders (user_id, product_id, quantity)
VALUES (999, 1, 5);
-- → DB phải kiểm tra: user_id=999 có tồn tại không?
-- → Nếu bảng users ở SERVER KHÁC → phải gọi qua network để verify
-- → CHẬM!

┌─────────────────────────────────────────────────────────────────────┐
│           FOREIGN KEY CHECK GIỮA CÁC SERVERS                        │
│                                                                     │
│   Server 1 (orders)              Server 2 (users)                   │
│   ┌────────────────┐             ┌────────────────┐                 │
│   │ INSERT order   │──verify──→  │ user_id=999    │                 │
│   │ user_id=999    │             │ exists?        │                 │
│   └────────────────┘             └────────────────┘                 │
│                                                                     │
│   Mỗi INSERT/UPDATE đều phải check FK qua network                   │
│   → Latency tăng                                                    │
│   → Throughput giảm                                                 │
│   → Nếu network lỗi → không INSERT được                             │
└─────────────────────────────────────────────────────────────────────┘

// Mỗi item trong DynamoDB chứa ĐẦY ĐỦ thông tin, không cần JOIN
{
    "order_id": "ORD-001",
    "order_date": "2024-06-15",
    "quantity": 2,

    // Thông tin user được NHÚNG trực tiếp vào (denormalized)
    "user": {
        "id": "U-123",
        "name": "Nguyễn Văn A",
        "email": "a@example.com"
    },

    // Thông tin product cũng được NHÚNG trực tiếp
    "product": {
        "id": "P-456",
        "name": "iPhone 15",
        "price": 25000000
    }
}

┌─────────────────────────────────────────────────────────────────────┐
│          NOSQL: MỖI RECORD ĐẦY ĐỦ THÔNG TIN                         │
│                                                                     │
│   Server 1                Server 2                Server 3          │
│   ┌─────────────┐        ┌─────────────┐        ┌─────────────┐     │
│   │ ORD-001     │        │ ORD-501     │        │ ORD-1001    │     │
│   │  user: {...}│        │  user: {...}│        │  user: {...}│     │
│   │  prod: {...}│        │  prod: {...}│        │  prod: {...}│     │
│   │             │        │             │        │             │     │
│   │ ORD-002     │        │ ORD-502     │        │ ORD-1002    │     │
│   │  user: {...}│        │  user: {...}│        │  user: {...}│     │
│   │  prod: {...}│        │  prod: {...}│        │  prod: {...}│     │
│   └─────────────┘        └─────────────┘        └─────────────┘     │
│                                                                     │
│   Query: Lấy đơn hàng ORD-501?                                      │
│   → Chỉ cần hỏi Server 2, KHÔNG cần hỏi server nào khác!            │
│   → Nhanh, đơn giản, không phụ thuộc server khác                    │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                    EVENTUAL CONSISTENCY                             │
│                                                                     │
│   Thời điểm T0: User A cập nhật tên thành "Nguyễn Văn B"            │
│                                                                     │
│   Server 1 (write)       Server 2 (replica)      Server 3 (replica) │
│   ┌─────────────┐       ┌─────────────┐         ┌─────────────┐     │
│   │ name: "B"   │  ──→  │ name: "A"   │   ──→   │ name: "A"   │     │
│   │ (đã update) │  sync │ (chưa sync) │   sync  │ (chưa sync) │     │
│   └─────────────┘       └─────────────┘         └─────────────┘     │
│                                                                     │
│   Thời điểm T0 + 50ms:                                              │
│   ┌─────────────┐       ┌─────────────┐         ┌─────────────┐     │
│   │ name: "B"   │       │ name: "B"   │         │ name: "A"   │     │
│   │ (đã update) │       │ (đã sync)   │         │ (chưa sync) │     │
│   └─────────────┘       └─────────────┘         └─────────────┘     │
│                                                                     │
│   Thời điểm T0 + 100ms: TẤT CẢ đã sync                              │
│   ┌─────────────┐       ┌─────────────┐         ┌─────────────┐     │
│   │ name: "B"   │       │ name: "B"   │         │ name: "B"   │     │
│   └─────────────┘       └─────────────┘         └─────────────┘     │
│                                                                     │
│   → Trong khoảng 50-100ms, đọc từ Server 3 sẽ thấy dữ liệu CŨ       │
│   → Nhưng SAU ĐÓ, tất cả sẽ consistent                              │
│   → Đổi lấy: tốc độ write cực nhanh + dễ scale                      │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│           PARTITION KEY TRONG DYNAMODB                              │
│                                                                     │
│   Partition Key = user_id                                           │
│   Hash function quyết định dữ liệu đi đâu                           │
│                                                                     │
│   hash("U-001") = 0x3A → Partition 1                                │
│   hash("U-002") = 0x7F → Partition 2                                │
│   hash("U-003") = 0xB2 → Partition 3                                │
│   hash("U-004") = 0x15 → Partition 1                                │
│                                                                     │
│   Partition 1          Partition 2          Partition 3             │
│   ┌──────────┐        ┌──────────┐        ┌──────────┐              │
│   │ U-001    │        │ U-002    │        │ U-003    │              │
│   │ U-004    │        │          │        │          │              │
│   └──────────┘        └──────────┘        └──────────┘              │
│                                                                     │
│   Khi cần thêm capacity → DynamoDB tự chia thêm partitions          │
│   → Hoàn toàn tự động, không cần can thiệp                          │
└─────────────────────────────────────────────────────────────────────┘

Ban đầu: 1 server MySQL
├── Bảng users (10 triệu rows)
├── Bảng products (5 triệu rows)
├── Bảng orders (100 triệu rows)
├── Bảng order_items (500 triệu rows)
├── Bảng reviews (50 triệu rows)
└── Bảng payments (100 triệu rows)

Vấn đề khi traffic tăng:
1. Query "Lấy tất cả đơn hàng của user X với chi tiết sản phẩm"
   → JOIN 4 bảng → chậm khi dữ liệu lớn

2. Mùa Flash Sale: 100,000 đơn hàng/phút
   → 1 server MySQL không xử lý nổi
   → Scale vertical: upgrade lên server 64 CPU?
   → Vẫn không đủ!

3. Muốn scale horizontal (sharding):
   → Chia users theo user_id range (1-5M → Server1, 5M-10M → Server2)
   → Nhưng query "tất cả orders của product X" phải hỏi TẤT CẢ servers
   → Cross-shard JOIN rất chậm
   → Code phải viết lại hoàn toàn để handle sharding logic

DynamoDB tables:
├── UserOrders (PK: user_id, SK: order_date#order_id)
│   → Chứa thông tin đầy đủ: user + order + products
│   → Query tất cả orders của 1 user: chỉ cần query 1 partition
│
├── ProductCatalog (PK: product_id)
│   → Chứa đầy đủ thông tin product
│   → Get product: single item read, cực nhanh
│
└── UserProfiles (PK: user_id)
    → Chứa đầy đủ thông tin user

Khi traffic tăng:
1. Flash Sale 100,000 đơn hàng/phút?
   → DynamoDB tự thêm partitions
   → Chỉ cần tăng WCU (Write Capacity Units)
   → Hoặc dùng On-Demand mode → tự scale

2. 10 triệu users?
   → Dữ liệu tự phân tán đều trên hàng nghìn partitions
   → Mỗi query chỉ access 1 partition → nhanh

3. Không cần viết lại code, không cần quản lý servers

-- Schema
CREATE TABLE messages (
    id BIGINT PRIMARY KEY,
    conversation_id INT,
    sender_id INT REFERENCES users(id),
    content TEXT,
    sent_at TIMESTAMP,
    read_at TIMESTAMP
);

-- Query: Lấy 50 tin nhắn mới nhất của conversation
SELECT m.*, u.name AS sender_name, u.avatar
FROM messages m
JOIN users u ON m.sender_id = u.id
WHERE m.conversation_id = 12345
ORDER BY m.sent_at DESC
LIMIT 50;

-- Vấn đề:
-- 1 tỷ messages → 1 bảng messages quá lớn
-- JOIN với users table mỗi lần load chat
-- Index trên conversation_id + sent_at rất lớn
-- Scale horizontal? → messages và users ở servers khác nhau → JOIN chậm

// Mỗi message chứa đầy đủ thông tin sender
// Table: Messages
// PK: conversation_id, SK: sent_at#message_id
{
    "conversation_id": "CONV-12345",
    "sent_at#message_id": "2024-06-15T10:30:00#MSG-789",
    "content": "Xin chào!",
    "sender": {
        "id": "U-001",
        "name": "Nguyễn Văn A",
        "avatar": "https://cdn.example.com/avatar/001.jpg"
    },
    "read_by": ["U-002", "U-003"]
}

// Query: Lấy 50 tin nhắn mới nhất
// → Chỉ cần query trên 1 partition (conversation_id)
// → Không cần JOIN
// → Cực nhanh, dù có 1 tỷ messages tổng cộng
// → Scale horizontal tự động

┌──────────────────────────────────────────────────────────────┐
│                     ACID (Relational DB)                     │
│                                                              │
│   ✅ Dữ liệu LUÔN chính xác                                  │
│   ✅ Phù hợp: Ngân hàng, tài chính, kế toán                  │
│   ❌ Khó scale horizontal                                    │
│   ❌ Chậm hơn khi phân tán                                   │
│                                                              │
│   Ví dụ: Chuyển tiền ngân hàng                               │
│   → PHẢI đảm bảo trừ A và cộng B CÙNG thành công             │
│   → Không chấp nhận "eventually" correct                     │
└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐
│                      BASE (NoSQL)                            │
│                                                              │
│   ✅ Scale horizontal dễ dàng                                │
│   ✅ Throughput cao, latency thấp                            │
│   ❌ Dữ liệu có thể "tạm thời" không nhất quán               │
│   ❌ Dữ liệu lặp lại (denormalized)                          │
│                                                              │
│   Ví dụ: Like trên Facebook                                  │
│   → 1 giây chênh lệch giữa "1,000 likes" và "1,001 likes"    │
│   → Không ai quan tâm → chấp nhận được                       │
└──────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                     RDS SCALING OPTIONS                             │
│                                                                     │
│   Vertical Scaling:                                                 │
│   db.t3.micro → db.t3.medium → db.r6g.xlarge → db.r6g.16xlarge      │
│   (2 vCPU)      (2 vCPU)       (4 vCPU)         (64 vCPU)           │
│   → Có giới hạn: max 64 vCPU, 512 GB RAM                            │
│                                                                     │
│   Read Replicas (một dạng horizontal scaling CHỈ cho READ):         │
│   ┌──────────┐     ┌──────────┐                                     │
│   │  Primary │────→│ Replica 1│  (read-only)                        │
│   │  (R+W)   │────→│ Replica 2│  (read-only)                        │
│   │          │────→│ Replica 3│  (read-only)                        │
│   └──────────┘     └──────────┘                                     │
│   → Max 5-15 replicas tùy engine                                    │
│   → CHỈ scale READ, KHÔNG scale WRITE                               │
│   → Write vẫn phải đi qua 1 Primary duy nhất                        │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                    AURORA SCALING OPTIONS                           │
│                                                                     │
│   → Lên tới 15 Read Replicas (tốt hơn RDS)                          │
│   → Auto Scaling replicas dựa trên load                             │
│   → Aurora Serverless: tự scale compute                             │
│   → Storage tự động tăng (max 128 TB)                               │
│                                                                     │
│   NHƯNG VẪN:                                                        │
│   → 1 Primary instance cho WRITE                                    │
│   → Không thể chia dữ liệu ra nhiều write nodes dễ dàng             │
│   → Multi-Master có nhưng giới hạn (max 4 write nodes)              │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                   DYNAMODB SCALING                                  │
│                                                                     │
│   Horizontal Scaling TỰ ĐỘNG:                                       │
│                                                                     │
│   Traffic thấp:                                                     │
│   ┌────────┐ ┌────────┐ ┌────────┐                                  │
│   │ Part 1 │ │ Part 2 │ │ Part 3 │      (3 partitions)              │
│   └────────┘ └────────┘ └────────┘                                  │
│                                                                     │
│   Traffic cao (tự động split):                                      │
│   ┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐┌────┐            │
│   │ P1 ││ P2 ││ P3 ││ P4 ││ P5 ││ P6 ││ P7 ││ P8 ││ P9 │            │
│   └────┘└────┘└────┘└────┘└────┘└────┘└────┘└────┘└────┘            │
│   (9 partitions - tự động, không cần can thiệp)                     │
│                                                                     │
│   ✅ Không giới hạn throughput (On-Demand mode)                     │
│   ✅ Không giới hạn storage                                         │
│   ✅ Single-digit millisecond latency dù TB dữ liệu                 │
│   ✅ Không cần quản lý servers                                      │
│   ✅ CẢ READ VÀ WRITE đều scale                                     │
└─────────────────────────────────────────────────────────────────────┘

users ←──FK──── orders ────FK──→ products
-- 3 bảng riêng, JOIN khi cần

// TABLE 1: Users (bản gốc, query độc lập được)
{ "PK": "USER#001", "name": "Nguyễn Văn A", "email": "a@example.com" }

// TABLE 2: Products (bản gốc, query độc lập được)
{ "PK": "PROD#001", "name": "iPhone 15", "price": 25000000 }

// TABLE 3: Orders (NHÚNG COPY của user + product)
{
    "PK": "USER#001",
    "SK": "ORDER#2024-06-15#ORD-001",
    "quantity": 2,
    "user_name": "Nguyễn Văn A",       // ← copy từ Users
    "product_id": "PROD#001",
    "product_name": "iPhone 15",        // ← copy từ Products
    "product_price": 25000000           // ← copy giá TẠI THỜI ĐIỂM MUA
}

// Products với tags được NHÚNG
{ "_id": "PROD-001", "name": "iPhone 15", "price": 25000000,
  "tags": ["electronics", "sale", "smartphone", "apple"] }

// Order chỉ lưu product_id (reference)
{ "_id": "ORD-001", "product_id": "PROD-001", "quantity": 2 }
// → Muốn biết tên product → phải query Products table riêng

Seller đổi giá iPhone từ 25tr → 22tr

1. Products table → UPDATE giá mới ✅
2. Orders cũ       → KHÔNG CẦN update!
   → Vì 25tr là giá lúc khách MUA, đó là giá chính xác (giống hóa đơn)
   → Orders mới từ bây giờ sẽ copy giá 22tr

Dữ liệu nhúng có cần TRUY CẬP ĐỘC LẬP không?

├── CÓ (products, users)    → VẪN CẦN collection riêng
│                             → Nhúng chỉ là COPY để đọc nhanh
│
└── KHÔNG (shipping address, order items)
    → KHÔNG CẦN collection riêng
    → Nhúng là nơi lưu DUY NHẤT

// Document riêng lưu danh sách tất cả tags
{ "PK": "METADATA", "SK": "ALL_TAGS",
  "tags": ["electronics", "sale", "smartphone", "apple", "laptop"] }

// Query: GET 1 item → cực nhanh
// Khi thêm tag mới → App phải cập nhật 2 chỗ:
//   1. Thêm tag vào product
//   2. Thêm tag vào metadata document (nếu chưa tồn tại)

┌──────────────────────────────────────────────────────────────────┐
│  LOẠI 1: WRITE CONFLICT (2 người ghi cùng lúc)                   │
│  → Giải quyết bằng: Version Locking, Atomic Ops                  │
│  → Cả SQL và NoSQL đều gặp                                       │
│                                                                  │
│  LOẠI 2: READ STALE DATA (đọc data cũ từ replica)                │
│  → Đây mới là EVENTUAL CONSISTENCY                               │
│  → Xảy ra khi có ASYNC REPLICATION                               │
│  → Cả SQL và NoSQL đều CÓ THỂ gặp                                │
└──────────────────────────────────────────────────────────────────┘

// DynamoDB: Optimistic Locking
// Document lưu thêm field "version"
{ PK: "PROD#001", name: "iPhone 15", stock: 10, version: 1 }

// Update với ConditionExpression:
await dynamodb.update({
    Key: { PK: "PROD#001" },
    UpdateExpression: "SET stock = :s, version = :newV",
    ConditionExpression: "version = :curV",   // chỉ update nếu version CHƯA ĐỔI
    ExpressionAttributeValues: {
        ":s": 9, ":newV": 2, ":curV": 1
    }
});
// → Nếu ai đó đã đổi version → thất bại → đọc lại → thử lại

// DynamoDB: Atomic counter — KHÔNG cần version
await dynamodb.update({
    Key: { PK: "PROD#001" },
    UpdateExpression: "SET stock = stock - :qty",
    ConditionExpression: "stock >= :qty",
    ExpressionAttributeValues: { ":qty": 1 }
});
// → DB đảm bảo atomic, 2 người update cùng lúc vẫn đúng

T0: User A ghi stock = 9 vào Primary

    Primary              Replica
    ┌──────────┐        ┌──────────┐
    │ stock: 9 │──sync──│ stock:10 │  ← CHƯA KỊP SYNC
    └──────────┘   ...  └──────────┘

T0 + 5ms: User B đọc từ Replica → thấy stock = 10 (SAI!)
T0 + 50ms: Replica sync xong → stock = 9 (ĐÚNG)

→ Trong 50ms, data "tạm thời" sai → "Eventually" sẽ đúng

Sync:  Client ghi → Primary ghi → ĐỢI Replica ghi → OK
       → Chậm hơn, nhưng LUÔN consistent

Async: Client ghi → Primary ghi → OK (Replica sync SAU)
       → Nhanh hơn, nhưng Replica CÓ THỂ chưa có data mới

SQL mặc định:   1 server → không replica → STRONG consistency
                 Chỉ khi thêm Read Replicas → mới bị eventual

NoSQL mặc định:  LUÔN replicate (3 copies, 3 AZs)
                  → TỪ ĐẦU đã eventual consistency

→ Eventual consistency = hệ quả của ASYNC REPLICATION
→ Ai có async replica thì bị, CẢ SQL LẪN NOSQL
→ NoSQL luôn có replica (by design) nên LUÔN gặp
→ SQL có thể chọn không dùng replica (nhưng mất HA)

await dynamodb.put({
    TableName: "Products",
    Item: {
        PK: "PROD#001", name: "iPhone 15 Pro Max", price: 25000000,
        category: "smartphones", tags: ["apple", "flagship"],
        images: ["https://cdn.example.com/iphone15.jpg"],
        created_at: "2024-06-15T10:00:00Z"
    }
});
// → 1 API call, single-digit ms. SQL cần INSERT vào nhiều bảng (products + tags + images).

// Lấy 1 product
const product = await dynamodb.get({ TableName: "Products", Key: { PK: "PROD#001" } });
// → Trả về ĐẦY ĐỦ (kể cả tags, images), không cần JOIN

// Lấy products theo category (dùng GSI)
const phones = await dynamodb.query({
    TableName: "Products", IndexName: "CategoryIndex",
    KeyConditionExpression: "category = :cat",
    ExpressionAttributeValues: { ":cat": "smartphones" }
});

// Cập nhật giá + thêm tag (chỉ update fields cần thiết)
await dynamodb.update({
    TableName: "Products", Key: { PK: "PROD#001" },
    UpdateExpression: "SET price = :p, tags = list_append(tags, :t)",
    ExpressionAttributeValues: { ":p": 22000000, ":t": ["hot-deal"] }
});

// Xóa 1 item: đơn giản
await dynamodb.delete({ TableName: "Carts", Key: { PK: "USER#001", SK: "PROD#001" } });

// Xóa product + tất cả reviews: phải xóa TỪNG item (không có CASCADE)
const items = await dynamodb.query({
    TableName: "Products", KeyConditionExpression: "PK = :pk",
    ExpressionAttributeValues: { ":pk": "PROD#001" }
});
await dynamodb.batchWrite({
    RequestItems: { Products: items.Items.map(i => ({ DeleteRequest: { Key: { PK: i.PK, SK: i.SK } } })) }
});
// SQL: DELETE FROM products WHERE id = 1 (CASCADE tự xóa liên quan)

Strong Consistency ◄────────────────────────────► Eventual Consistency
(Chính xác)                                       (Nhanh, Scale)

    SQL (RDS)           MongoDB              DynamoDB
       ●───────────────────●────────────────────●
    "Phải đúng"    "Cố gắng đúng,         "Nhanh trước,
                    nhưng vẫn nhanh"       đúng sau"

┌─────────────────────────────────────────────────────────────────┐
│   Cần ACID / Transactions phức tạp?                             │
│   ├── CÓ → SQL (RDS/Aurora)                                     │
│   └── KHÔNG ↓                                                   │
│                                                                 │
│   Cần scale lớn + không muốn quản lý server?                    │
│   ├── CÓ → DynamoDB                                             │
│   └── KHÔNG ↓                                                   │
│                                                                 │
│   Cần query linh hoạt + team tự quản lý được?                   │
│   ├── CÓ → MongoDB                                              │
│   └── KHÔNG → SQL (mặc định, đơn giản nhất)                     │
└─────────────────────────────────────────────────────────────────┘