Chọn database, cache và queue

Chọn kho dữ liệu theo cách dữ liệu được đọc và ghi. Hỏi bốn câu trước khi chọn: dữ liệu có quan hệ và cần transaction không, tỉ lệ đọc ghi thế nào, truy vấn theo khoá hay theo điều kiện phức tạp, và dữ liệu lớn bao nhiêu sau vài năm. Mọi con số giới hạn trong bài là ước lượng cho máy cỡ vừa, thuộc quy tắc ước lượng của khoá học trừ chỗ có ghi nguồn sách.¹ Grokking ch.5 cho vài mốc tham chiếu: một MySQL đơn lẻ khoảng 1.000 QPS, key-value store khoảng 10.000 QPS, cache server từ 100.000 đến 1 triệu QPS, và nhấn mạnh các số này thay đổi nhiều theo loại truy vấn, cấu hình máy, thiết kế DB và index.²

Bảng chọn nhanh

Mặc định an toàn cho hầu hết sản phẩm là PostgreSQL. Nó đủ cho transaction, JSON, full-text cơ bản, và với PostGIS thì cả dữ liệu vị trí. Chỉ thêm kho khác khi có con số cho thấy Postgres không đáp ứng. Grokking ch.9 so sánh SQL và NoSQL theo cùng tinh thần: chọn relational khi dữ liệu có cấu trúc, cần ACID và vừa một node; chọn non-relational khi dữ liệu phi cấu trúc, rất lớn, cần scale ngang dễ và chấp nhận mô hình nhất quán yếu hơn như eventual consistency.³ Sách mô tả key-value hợp với tải theo phiên (session), document hợp với dữ liệu catalog không cố định cấu trúc, columnar hợp với tổng hợp nhiều dòng, graph hợp với dữ liệu quan hệ.⁴ Bảng nhanh phía trên, gồm cả cột ngưỡng một node, là bảng ước lượng của khoá học, còn tên sản phẩm cụ thể (Cassandra, TimescaleDB…) chưa có sách trong thư viện.⁵

Đọc nhiều hay ghi nhiều

Tỉ lệ đọc ghi quyết định hướng scale. Building Microservices ch.11 tách riêng hai trường hợp: đọc dễ scale hơn ghi nhiều, còn scale ghi là chỗ mọi thứ trở nên khó.⁶⁷

• Đọc nhiều: cache trước. Building Microservices khuyên nghĩ đến caching trước read replica vì thường cải thiện hiệu năng nhiều hơn với ít công hơn.⁶ Hit 90% nghĩa là DB chỉ nhận 10% lượt đọc (phép tính). Sau đó thêm read replica: mô hình primary-secondary hợp với tải đọc nhiều, thêm follower để chia tải đọc, nhưng replicate bất đồng bộ thì đọc từ replica có thể thấy dữ liệu cũ.⁸ Con số mỗi replica lập kế hoạch khoảng 3.000 truy vấn đọc/s và "trễ vài trăm ms" là ước lượng của khoá học.¹ Chi tiết ở Scale đọc.
• Ghi nhiều: replica không giúp vì mọi ghi vẫn vào primary; Grokking nói primary-secondary không phù hợp khi tải ghi nặng.⁸ Gom ghi qua queue để hấp thụ đỉnh,⁹ partition bảng, rồi shard: chia dữ liệu ra nhiều node, mỗi node giữ một phần.¹⁰ Building Microservices cảnh báo sharding làm truy vấn xuyên shard phức tạp, và khi chạm giới hạn ghi thì mua máy to hơn thường là cách nhanh nhất trong lúc tìm giải pháp lâu dài.⁷ Chi tiết ở Scale ghi và Sharding.

Ngưỡng cấu hình Postgres khoá dùng (theo tải DB sau cache, quy tắc ước lượng của khoá học):¹

Cache

• Cache-aside là mặc định: đọc cache, trượt thì đọc DB rồi ghi lại cache với TTL. Grokking mô tả chính sách gần nhất là write-around: ghi thẳng DB, khi đọc trượt cache thì mới nạp vào cache, nhưng không tốt để đọc lại dữ liệu vừa ghi.¹¹
• Write-through khi cần cache luôn mới: ghi cả cache và DB, tăng độ trễ ghi nhưng giữ nhất quán mạnh giữa hai nơi. Write-back ghi cache trước rồi ghi DB bất đồng bộ, độ trễ ghi thấp nhưng có thể không nhất quán.¹¹
• Đo bằng tỉ lệ hit. Hit 85% là mức khởi đầu hợp lý cho dữ liệu đọc nhiều (giả định của khoá học).¹
• Cẩn thận cache stampede khi key nóng hết hạn: dùng khoá đơn (lock) hoặc làm mới sớm có xác suất (cách của khoá học). Building Microservices mô tả nguy cơ tương tự ở dạng "thundering herd" khi cache mất, và đề xuất để origin tự nạp lại cache bất đồng bộ thay vì để mọi request đổ vào origin.¹²
• Cẩn thận hot key: một key nhận quá nhiều lượt đọc dồn vào một node. Grokking gọi là "hotkey problem"; giải pháp trong sách là thêm replica (primary-secondary) cho shard nóng để chia tải đọc.¹³ Sao chép key ra nhiều bản hoặc cache thêm trong process là cách của khoá học.¹

Grokking ch.16 bàn các chính sách thay thế (LRU, LFU) và cách chia cache ra nhiều node.¹⁴ Khoá này chi tiết hơn ở bài Caching.

async function getProduct(id: string) {
  const key = `product:${id}`;
  const hit = await redis.get(key);
  if (hit) return JSON.parse(hit);
  const row = await db.query("SELECT * FROM products WHERE id = $1", [id]);
  await redis.set(key, JSON.stringify(row), "EX", 300);
  return row;
}

Queue

Dùng queue khi việc có thể làm sau, khi cần hấp thụ đỉnh, hoặc khi một sự kiện cần nhiều bên xử lý. Grokking ch.17 nêu đúng các lợi ích này: xử lý bất đồng bộ để tách việc chậm khỏi đường đi chính, tăng độ tin cậy vì producer và consumer hỏng độc lập, decoupling, và hấp thụ đỉnh tải như một dạng rate limiting thô.⁹

Gần như mọi queue giao ít nhất một lần: Grokking giải thích message chỉ bị xoá khi consumer gọi xoá, nên nếu worker lỗi thì worker khác nhận lại, tức at-least-once.¹⁵ Vì vậy consumer phải idempotent: lưu id đã xử lý, hoặc dùng upsert theo khoá tự nhiên (hướng xử lý của khoá học).¹ Các so sánh sản phẩm trong bảng (BullMQ, SQS, Kafka, số MB/s) chưa có sách trong thư viện.¹⁶ Xem Kafka và Tác vụ dài.

Object storage và CDN

File, ảnh, video không nên nằm trong database. Đặt ở object storage (S3, GCS, R2), database chỉ giữ metadata và đường dẫn. Grokking ch.20 mô tả blob store là kho cho dữ liệu phi cấu trúc (ảnh, video, tệp nhị phân), chia dữ liệu thành các chunk trên data node và giữ metadata (tài khoản, container, vị trí blob) ở một kho metadata riêng, đúng cách tách này.¹⁷

• Client upload thẳng lên storage bằng presigned URL, API không phải trung chuyển byte.¹⁸
• File lớn dùng multipart upload (chia thành chunk, khớp cách blob store chia chunk). Xem File lớn.¹⁷
• Đặt CDN phía trước cho nội dung đọc nhiều. Grokking ch.11 nêu ba vấn đề CDN giải quyết: độ trễ cao do khoảng cách tới data center, ứng dụng nhiều dữ liệu khiến origin phải gửi dữ liệu trùng lặp, và tài nguyên data center có hạn (kèm nguy cơ điểm chết duy nhất); CDN là nhóm proxy server phân tán địa lý để phục vụ từ gần người dùng.¹⁹
• Chi phí lưu trữ object khoảng 0,02 USD/GB/tháng và chi phí băng thông ra thường lớn hơn chi phí lưu trữ là số ước lượng theo nhà cung cấp, không có trong sách.¹⁸

Managed hay tự vận hành

Phần này là đánh giá vận hành của khoá học; sách trong thư viện không so sánh managed với tự vận hành, và hệ số chi phí 1,5–2 lần là giả định.²⁰

Một kỹ sư vận hành tốn hơn chênh lệch hoá đơn của vài database cỡ vừa. Vì vậy mặc định là managed. Tự vận hành chỉ hợp lý khi hoá đơn đủ lớn để trả cho một đội chuyên trách.

Ví dụ tính cấu hình

Phép tính dưới đây dùng quy tắc ước lượng của khoá học (xem Chọn server).¹ Giả định như bài đó: 30 request/người/ngày, đỉnh ×5, 10% ghi, mỗi ghi 1 KB, cache hit 85%, 2 triệu item nóng mỗi item 1 KB.

1 triệu DAU:

1. Đỉnh ≈ 1.736 req/s, gồm ≈ 174 ghi và ≈ 1.562 đọc.
2. Đọc xuống DB sau cache: 1.562 × 0,15 ≈ 234. Tổng tải DB ≈ 408 q/s.
3. Database: 4 vCPU · 16 GB, primary + standby. Read replica: ceil(234 ÷ 3.000) = 1, tức 0–1 replica.
4. Redis: 2.000.000 × 1.100 × 1,3 ≈ 2,9 GB, node 4 GB có replica.
5. Lưu trữ: 1.000.000 × 30 × 10% × 1 KB × 365 ≈ 1,1 TB/năm. Sau khoảng 1,5 năm chạm ngưỡng 1–2 TB của một node, cần partition theo thời gian và chuyển dữ liệu cũ ra kho lạnh.
6. Queue: SQS hoặc BullMQ cho job nền.

50 triệu DAU:

1. Đỉnh ≈ 86.806 req/s, ghi ≈ 8.681/s.
2. Tải DB sau cache ≈ 8.681 + 78.125 × 0,15 ≈ 20.400 q/s, vượt 15.000: cần shard hoặc DB phân tán.
3. Lưu trữ ≈ 55 TB/năm: dữ liệu ghi nhiều theo khoá hợp với Cassandra hoặc DynamoDB, dữ liệu giao dịch giữ ở Postgres đã shard.
4. Redis Cluster vì đỉnh vượt 80.000 thao tác/s trên một node.
5. Kafka làm xương sống sự kiện, đọc lại được khi thêm consumer mới.

Bạn có thể đổi giả định trong Máy tính hạ tầng.