Cache strategies - Lựa chọn chiến lược nào cho dự án của bạn?

I. Giới thiệu

Bạn hẳn đã quen thuộc với khái niệm cache rồi nhỉ? Khi ứng dụng chạy chậm, giải pháp thường nghĩ đến là dùng cache – nghe có vẻ đơn giản. Nhưng triển khai cache như thế nào để vừa đạt hiệu quả cao, vừa đảm bảo tính chính xác của dữ liệu lại là một bài toán không hề dễ.

Trong bài viết này, chúng ta sẽ cùng tìm hiểu 5 chiến lược caching phổ biến, phân tích ưu nhược điểm của từng chiến lược và khám phá cách áp dụng chúng vào các tình huống thực tế để tối ưu hiệu suất hệ thống nhé.

II. Read strategies

2.1. Cache-aside (lazy load)

Cache-aside hoạt động dựa trên nguyên tắc chỉ lưu cache khi cần thiết. Nói cách khác, dữ liệu sẽ chỉ được đưa vào cache nếu có yêu cầu đọc mà cache không chứa dữ liệu đó (cache miss). Trong mô hình này, ứng dụng chịu trách nhiệm cả việc truy vấn dữ liệu từ nguồn gốc (ví dụ: database) và cả việc lưu dữ liệu đó vào cache.

Ví dụ:

1. Người dùng yêu cầu thông tin sản phẩm A.
2. Ứng dụng kiểm tra cache:
   • Nếu có (cache hit), trả ngay dữ liệu từ cache.
   • Nếu không (cache miss), lấy dữ liệu từ database và trả lại cho người dùng.
3. Lưu thông tin sản phẩm A vào cache để dùng cho các lần truy vấn sau.

Ưu điểm:

• Khả năng chịu lỗi cao: Nếu cache gặp sự cố, ứng dụng vẫn có thể truy xuất dữ liệu từ database mà không ảnh hưởng đến tính ổn định của hệ thống.
• Tính linh hoạt cao: Bạn có thể tùy chỉnh cách lưu trữ và tổ chức dữ liệu trong cache, có thể khác biệt hoàn toàn so với mô hình dữ liệu trong database. Ví dụ, thay vì lưu toàn bộ thông tin của sản phẩm A, bạn chỉ lưu một vài thông tin cần thiết như tên và giá sản phẩm vào cache. Điều này giúp tối ưu hóa hiệu suất và tiết kiệm bộ nhớ, đồng thời linh hoạt hơn trong việc xử lý các trường hợp sử dụng cụ thể.

Nhược điểm:

• Độ trễ ban đầu: Lần đầu truy cập dữ liệu bị cache miss, ứng dụng sẽ phải truy xuất từ database, làm tăng độ trễ.
• Quản lý phức tạp: Ứng dụng phải quản lý đồng thời cả cache và database, điều này có thể khiến code trở nên phức tạp hơn, đặc biệt khi phải xử lý các tình huống liên quan đến đồng bộ giữa hai hệ thống.
• Khó đảm bảo tính nhất quán: Việc duy trì tính nhất quán giữa cache và database là một thách thức lớn, vì các thao tác trên cache và database không đảm bảo được thực hiện một cách nhất quán (atomic operations).

Ví dụ về việc khó đảm bảo tính nhất quán:

• Vào lúc 2:00 PM, người dùng yêu cầu xem thông tin sản phẩm "Laptop A" và ứng dụng trả về số lượng còn lại là 10 từ cache.
• Vào lúc 2:15 PM, một nhân viên kho hàng cập nhật số lượng "Laptop A" trong database xuống còn 5 sản phẩm, nhưng cache vẫn chưa được làm mới.
• Khi một người dùng khác yêu cầu xem sản phẩm "Laptop A" vào lúc 2:30 PM, ứng dụng vẫn trả về số lượng cũ là 10 thay vì 5, gây ra tình trạng không đồng nhất giữa dữ liệu trong cache và database (cache invalidation).

Giải pháp khắc phục:

Bài viết này tập trung vào các chiến lược cache, do đó chúng ta sẽ không đi sâu vào tất cả các khía cạnh của việc giải quyết vấn đề không nhất quán dữ liệu. Tuy nhiên, dưới đây là một số phương pháp phổ biến để bạn có thể tham khảo.

• Thiết lập TTL (Time-To-Live): giúp đảm bảo rằng dữ liệu cũ sẽ tự động bị loại bỏ sau một khoảng thời gian nhất định, giảm thiểu khả năng xảy ra tình trạng không đồng bộ.
• Kết hợp với các chiến lược ghi dữ liệu khác: Đối với các trường hợp cần tính nhất quán cao hơn về dữ liệu, có thể áp dụng thêm các chiến lược như write-through hoặc write-behind để cải thiện tính nhất quán giữa cache và database Các chiến lược này sẽ được đề cập trong các phần sau của bài viết.

Trường hợp sử dụng:

Cache-aside phù hợp với trường hợp đọc nhiều, ghi ít. Khi mà dữ liệu được đọc thường xuyên nhưng ít khi thay đổi. Một ví dụ điển hình là cache thông tin người dùng trên mạng xã hội facebook, twitter (tên, ảnh đại diện, số lượng bạn bè).

Cache-aside không phù hợp với các trường hợp sau:

• Dữ liệu thay đổi liên tục: Ví dụ: giá cổ phiếu, tỷ giá tiền tệ. Việc cập nhật cache liên tục sẽ gây tốn kém.
• Yêu cầu tính nhất quán cao: Ví dụ: hệ thống ngân hàng, đặt vé máy bay. Sai lệch dữ liệu dù nhỏ cũng có thể gây hậu quả nghiêm trọng.
• Ghi nhiều hơn đọc: Ví dụ: hệ thống log, phân tích dữ liệu thời gian thực. Chi phí duy trì cache có thể lớn hơn lợi ích.

2.2. Read-through

Khác với chiến lược cache-aside, nơi mà ứng dụng đóng vai trò quyết định việc lấy dữ liệu từ đâu, chiến lược read-through sử dụng một lớp trung gian để tự động đưa dữ liệu từ database vào cache. Ứng dụng chỉ cần giao tiếp với cache để lấy dữ liệu mà không cần phải quan tâm đến việc dữ liệu đến từ đâu. Điều này giúp giảm bớt sự phức tạp trong code của ứng dụng.

Quy trình của read-through bao gồm các bước sau:

1. Ứng dụng yêu cầu dữ liệu từ cache.

2. Nếu dữ liệu không có trong cache:

   • Cache tự động lấy dữ liệu từ database .
   • Lưu dữ liệu vào cache.
   • Trả dữ liệu về cho ứng dụng.

Ưu điểm:

• Đơn giản hóa mã nguồn ứng dụng: Ứng dụng không cần phải quản lý việc lấy dữ liệu từ database và lưu vào cache. Các thao tác này đều do cache xử lý, giúp mã nguồn của ứng dụng trở nên dễ bảo trì hơn.

• Tăng tốc độ truy xuất dữ liệu: Dữ liệu thường xuyên được yêu cầu sẽ luôn có sẵn trong cache, giảm thời gian truy vấn từ database hoặc máy chủ gốc.

Nhược điểm:

• Vấn đề với độ tin cậy: Hệ thống có thể gặp sự cố nếu cache bị lỗi. Nếu cache tèo, ứng dụng sẽ có thể gặp sự cố không thể truy cập.
• Giới hạn tính linh hoạt: Cache và hệ thống lưu trữ phải sử dụng cùng một mô hình dữ liệu. Điều này có thể làm giảm khả năng linh hoạt khi xử lý các trường hợp sử dụng phức tạp hoặc dữ liệu có cấu trúc khác biệt.
• Vấn đề về tính nhất quán: Tương tự như chiến lược cache-aside, chiến lược này cũng gặp phải thách thức cache invalidation. Nếu dữ liệu trong database được cập nhật sau khi đã được lưu vào cache, nó có thể bị sai lệch so với dữ liệu thực tế trong database.

Trường hợp sử dụng:

Read-through phù hợp với các hệ thống đọc nhiều, ghi ít và cần đơn giản hóa code. CDN (Content Delivery Network) là một ví dụ, dữ liệu sẽ được lưu vào các edge server (cache) gần vị trí của người dùng giúp giảm thời gian load data. Người dùng chỉ cần gọi URL của CDN mà không cần quan tâm nội dung đó đến từ đâu.

Read-through không phù hợp với các trường hợp sau:

• Cần khả năng tùy biến cao: Ví dụ: các hệ thống cần cache một phần thông tin hoặc biến đổi dữ liệu trước khi lưu cache.
• Yêu cầu độ tin cậy cao: Ví dụ: các hệ thống không thể chấp nhận downtime khi cache gặp sự cố.
• Dữ liệu phức tạp: Ví dụ: hệ thống cần tổng hợp dữ liệu từ nhiều nguồn khác nhau trước khi cache.

III. Write strategies

3.1. Write-through

Write-through là chiến lược mà việc ghi dữ liệu sẽ được thực hiện đồng thời trên cả cache và database. Điểm đặc biệt của phương pháp này là chỉ khi dữ liệu được ghi thành công vào cả hai nơi, thao tác ghi mới được coi là hoàn thành. Điều này giúp đảm bảo tính nhất quán, rất phù hợp với các hệ thống yêu cầu độ chính xác cao.

Cách hoạt động:

1. Ứng dụng thực hiện thao tác ghi dữ liệu tới hệ thống cache.
2. Hệ thống cache sẽ tự động thực hiện việc ghi dữ liệu vào cả cache và database.
3. Chỉ khi cả hai thao tác ghi vào cache và database đều thành công, thao tác ghi mới được xem là hoàn tất.
4. Nếu một trong hai thao tác thất bại, toàn bộ giao dịch sẽ bị rollback để đảm bảo tính nhất quán.

Điểm mấu chốt là ứng dụng không tự ghi vào cache rồi mới ghi vào database. Ứng dụng chỉ tương tác với hệ thống cache.

Ưu điểm:

• Application chỉ cần ghi dữ liệu vào bộ nhớ đệm, đơn giản hóa quy trình và giảm độ phức tạp.
• Đảm bảo tính nhất quán của dữ liệu: Khi có một sự kiện update, dữ liệu sẽ được cập nhật một cách đồng bộ giữa cache và database. Điều này đảm bảo rằng cả hai hệ thống luôn có dữ liệu nhất quán.
• Ngoài ra, nó cũng rất phù hợp với các hệ thống có dữ liệu được read nhiều nhưng write thấp, chẳng hạn như danh mục sản phẩm, quản lý cấu hình hệ thống hoặc dữ liệu tham chiếu.

Nhược điểm:

• Hiệu năng thấp: Việc đồng bộ dữ liệu vào cả cache và database sau mỗi thao tác ghi có thể làm giảm hiệu suất. Điều này không chỉ tăng tải lên database mà còn có thể gây ra bottleneck trong các hệ thống có tần suất ghi cao. Vì vậy, chiến lược write-through không phù hợp cho các tác vụ yêu cầu ghi liên tục (chẳng hạn như ghi log).
• Lãng phí dung lượng cache: nếu có nhiều dữ liệu được ghi nhưng không được đọc lại.
• Khó khăn khi xử lý lỗi: Dữ liệu cần phải được ghi đồng thời vào cả cache và database. Điều này có thể dẫn đến những vấn đề trong trường hợp một trong hai thao tác ghi không thành công. Để đảm bảo tính nhất quán giữa hai hệ thống, bạn sẽ cần triển khai các cơ chế để đảm bảo rằng nếu có lỗi trong quá trình ghi, toàn bộ giao dịch sẽ bị rollback, tránh tình trạng dữ liệu không đồng bộ.

Trường hợp sử dụng:

Write-through phù hợp với các hệ thống cần đảm bảo tính nhất quán cao giữa cache và database. DAX (DynamoDB Accelerator) là một ví dụ, nó hoạt động như một bộ nhớ cache in-memory cho Amazon DynamoDB. Khi ứng dụng ghi dữ liệu, DAX tự động lưu trữ vào cả cache và DynamoDB, đồng thời tự động xử lý đồng bộ hóa và các tình huống lỗi mà không cần sự can thiệp của ứng dụng.

Write-through không phù hợp với các trường hợp sau:

• Yêu cầu hiệu năng cao cho thao tác ghi: Ví dụ: hệ thống xử lý log hoặc analytics nơi tốc độ ghi là ưu tiên hàng đầu.
• Dữ liệu có tính tạm thời: Ví dụ: cache session người dùng hoặc trạng thái tạm thời, việc ghi ngay vào database là không cần thiết.
• Tài nguyên hạn chế: Ví dụ: các hệ thống nhúng hoặc IoT, nơi chi phí cho việc ghi đồng thời vào cả cache và database có thể vượt quá ngân sách cho phép.

3.2. Write-back (write-behind)

Khác với write-through, write-back là chiến lược ghi không đồng bộ vào cache và database. Phương pháp này giúp cải thiện hiệu suất ghi vào database bằng cách thay vì liên tục ghi vào database ngay lập tức, dữ liệu sẽ được ghi vào cache trước, và sau đó được tích lũy lại và ghi vào database theo chu kỳ (từng lô lớn). Điều này giúp giảm tải cho database và cải thiện tốc độ thực thi các thao tác ghi.

Ưu điểm:

• Giảm độ trễ ghi: Vì dữ liệu được ghi vào cache trước, các thao tác ghi sẽ không bị trì hoãn bởi việc đồng bộ ngay lập tức với database, giúp giảm độ trễ ghi. Điều này rất hữu ích trong các ứng dụng yêu cầu tốc độ ghi cao và phản hồi nhanh.

• Giảm số lần ghi vào hệ thống lưu trữ chính: Write-back giảm tổng số lần ghi vào database, vì thay vì ghi từng lần thay đổi, các bản ghi được lưu trữ trong cache và được đồng bộ theo từng lô lớn. Điều này có thể làm giảm tải cho database và giảm chi phí ghi.

• Tăng khả năng chống chịu lỗi: Trong một số trường hợp, nếu hệ thống gặp sự cố và không thể ghi dữ liệu vào database ngay lập tức, dữ liệu vẫn có thể được lưu trữ trong cache, cho phép phục hồi sau khi hệ thống hoạt động lại.

Nhược điểm:

• Dữ liệu tạm thời không nhất quán: Do việc ghi vào database bị trì hoãn, trong khoảng thời gian này, dữ liệu trong cache có thể không đồng bộ với database. Nhưng biết sao được, phải đánh đổi để lấy hiệu suất mà.
• Nguy cơ mất dữ liệu: Nếu cache gặp sự cố trước khi dữ liệu được ghi vào database, các bản ghi cập nhật gần nhất có thể bị mất, dẫn đến mất mát dữ liệu.
• Phức tạp trong việc quản lý dữ liệu: Write-back yêu cầu hệ thống phải có cơ chế để đảm bảo rằng dữ liệu sẽ được đồng bộ hóa từ cache vào database trong các chu kỳ định kỳ. Điều này có thể phức tạp hơn khi phải đảm bảo tính toàn vẹn và đồng bộ khi có lỗi xảy ra.

Trường hợp sử dụng:

Một số ví dụ về cơ chế write-back được sử dụng trong thực tế bao gồm:

• Ổ cứng SSD: Ghi dữ liệu không đồng bộ vào cache của ổ cứng, sau đó ghi vào đĩa theo từng chu kỳ để tối ưu hóa hiệu suất.
• Ghi log: Lưu trữ dữ liệu ghi vào buffer/cache trước khi chuyển đến hệ thống lưu trữ chính (ví dụ, log system hoặc log file).
• Ứng dụng tin nhắn: Đồng bộ tin nhắn giữa local storage (hoặc database tạm) với cloud, giúp giảm độ trễ và tải mạng.

Việc sử dụng write-back đòi hỏi phải xem xét kỹ lưỡng. Nếu mục tiêu của bạn là tối ưu hóa hiệu suất và bạn đã có các biện pháp sao lưu đáng tin cậy, đây có thể là lựa chọn phù hợp. Tuy nhiên, nếu tính toàn vẹn dữ liệu là ưu tiên và bạn không thể chấp nhận bất kỳ sự sai lệch nào, write-through có thể là lựa chọn an toàn hơn, dù có thể chậm hơn một chút.

3.3. Write-around

Chiến lược write-around là một chiến lược phổ biến. Cách thức hoạt động của chiến lược này là ứng dụng sẽ ghi dữ liệu trực tiếp vào database mà không cập nhật cache ngay lập tức. Thay vào đó, dữ liệu sẽ chỉ được đưa vào cache khi có yêu cầu đọc trong tương lai, thông qua các chiến lược như cache-aside hoặc read-through. Flow cơ bản của write-around sẽ như sau:

1. Ứng dụng ghi dữ liệu trực tiếp vào hệ thống lưu trữ.
2. Sau khi dữ liệu được ghi vào hệ thống lưu trữ, có thể thực hiện một trong các bước sau:

• Ghi cặp key-value vào cache. Tuy nhiên, cách này có thể dẫn đến xung đột khi nhiều luồng cùng cập nhật một key.
• Vô hiệu hóa (invalidate) key trong cache. Đây là lựa chọn phổ biến, đảm bảo rằng các lần đọc sau đó sẽ gặp cache miss, và giá trị mới nhất sẽ được lấy từ hệ thống lưu trữ.
• Không làm gì với cache, chỉ dựa vào cơ chế Time-To-Live (TTL) để tự động vô hiệu hóa dữ liệu cũ trong cache.

Hãy tìm hiểu cách hoạt động của write-around cache thông qua ví dụ về quản lý sản phẩm trên sàn thương mại điện tử:

1. Khi tạo sản phẩm mới:

   • Admin tạo sản phẩm A với số lượng tồn kho là 10
   • Theo chiến lược write-around, dữ liệu chỉ được lưu vào database mà không lưu vào cache
   • Kết quả: Database có thông tin sản phẩm A, cache chưa có dữ liệu

2. Khi khách hàng xem sản phẩm lần đầu:

   • Hệ thống kiểm tra cache → Không tìm thấy dữ liệu (cache miss)
   • Hệ thống query database để lấy thông tin sản phẩm A
   • Sau khi lấy được dữ liệu, hệ thống lưu vào cache để phục vụ các request sau
   • Trả về thông tin sản phẩm cho khách hàng

3. Khi khách hàng khác xem sản phẩm:

   • Hệ thống kiểm tra cache → Tìm thấy dữ liệu (cache hit)
   • Trả về thông tin trực tiếp từ cache, không cần query database

Có thể thấy lần đầu tiên truy cập sẽ bị cache miss, nhưng từ lần truy cập thứ 2 trở đi, tốc độ truy xuất rất nhanh nhờ có cache. Chiến lược write-around đánh đổi "lần đầu tiên" để lấy tiết kiệm bộ nhớ cache vốn đã eo hẹp. Chỉ những dữ liệu thực sự được truy vấn mới được thêm vào cache mà thôi. Việc này sẽ phù hợp với các ứng dụng có dữ liệu được thêm vào nhiều nhưng chỉ một số hot data mới được truy cập thường xuyên như sản phẩm trên các sàn thương mại điện tử.

Tuy nhiên, câu chuyện chưa hết ở đây, tiếp theo chúng ta sẽ tới bước cập nhật sản phẩm.

4. Khi admin cập nhật sản phẩm:
   • Admin giảm tồn kho sản phẩm A từ 10 xuống 1
   • Vấn đề lúc này bắt đầu xuất hiện, đó chính là cache invalidation. Trong cache vẫn là 10, nhưng database lại là 1, nếu khách hàng xem thông tin sẽ bị sai lệch.

Để giải quyết vấn đề này, cần thêm cơ chế invalidate cache như đã đề cập ở phần workflow. Tóm lại...

Ưu điểm

• Tiết kiệm bộ nhớ cache: Chỉ những dữ liệu thực sự được truy cập mới nằm trong cache. Phù hợp với sàn TMĐT sản phẩm nhưng chỉ một phần nhỏ được xem thường xuyên.
• Tính linh hoạt cao: Application chủ động trong việc xử lý dữ liệu, không bị phụ thuộc vào cache.

Nhược điểm

• Tăng độ phức tạp: Cần thêm logic để quản lý việc invalidate cache khi có yêu cầu update dữ liệu.
• Cache miss: Trong lần đầu tiên, dữ liệu chỉ được lưu vào database, do đó nếu có yêu cầu gọi thì sẽ bị cache miss. Độ trễ cao hơn cho lần đọc đầu tiên do phải load từ database vào cache.

Trường hợp sử dụng:

Write-around phù hợp với các hệ thống có dữ liệu được ghi nhiều nhưng đọc ít. Ví dụ CDN, nơi nội dung mới được ghi trực tiếp vào storage và chỉ được cache tại các edge server khi có yêu cầu truy cập từ người dùng.

Write-around không phù hợp với các trường hợp sau:

• Dữ liệu thường xuyên được cập nhật và đọc: Ví dụ: bảng xếp hạng game online, nơi điểm số liên tục thay đổi và người chơi thường xuyên xem.
• Dữ liệu có tính chất hot data: Ví dụ với các trang mạng xã hội lớn. Bài viết mới thường được đưa vào cache ngay lập tức để phục vụ các lượt truy cập lớn sau khi đăng, đặc biệt với nội dung nóng hổi hoặc trending.

IV. Kết hợp các phương pháp

Các chiến lược cache có thể được kết hợp để tạo ra các giải pháp caching mạnh mẽ và hiệu quả, phù hợp với các trường hợp sử dụng và yêu cầu cụ thể.

4.1. Một số kết hợp phổ biến

Cache-aside & write-around: Đây là một kết hợp phổ biến nhất trong lập trình backend, đặc biệt trong các hệ thống như Memcached và Redis, nơi cache-aside tối ưu hóa thao tác đọc, còn write-around giúp giảm áp lực ghi vào cache. Dữ liệu chỉ được ghi vào cache khi có truy cập thực tế, tránh lãng phí tài nguyên cache cho dữ liệu ít được truy cập.

Read-through & write-through: Kết hợp này sử dụng cache như một lớp trung gian, đảm bảo mọi thao tác đọc và ghi đều đi qua cache, giúp duy trì tính nhất quán.

• Ví dụ: DynamoDB Accelerator (DAX), nơi read-through phục vụ đọc nhanh từ cache, và write-through đảm bảo ghi đồng bộ qua cache vào DynamoDB.

Read-through & write-back: Đây là một kết hợp hiệu quả khi cần hiệu suất cao. Read-through đảm bảo việc đọc được ủy thác qua cache, còn write-back cải thiện hiệu suất ghi nhờ tính không đồng bộ, ghi dữ liệu trực tiếp vào cache và đẩy về hệ thống lưu trữ sau.

• Một ví dụ thực tế về cách kết hợp này có thể áp dụng là hệ thống bảng xếp hạng (leaderboard) trong các game online. Read-through sẽ lấy dữ liệu bảng xếp hạng và điểm số hiện tại, trong khi write-back giúp cập nhật điểm số mới theo lô (batch), giảm tải cho cơ sở dữ liệu.
• Lưu ý: Tính không đồng bộ của write-back có thể gây rủi ro mất dữ liệu nếu cache gặp sự cố trước khi đồng bộ về hệ thống lưu trữ.

4.2. Các kết hợp ít phổ biến hơn

Read-through & write-around: Read-through tối ưu thao tác đọc qua cache, trong khi write-around giúp ghi trực tiếp vào hệ thống lưu trữ mà không làm quá tải cache. Kết hợp này có thể hiệu quả trong các hệ thống có tỷ lệ đọc cao, nhưng không yêu cầu phản ánh ngay các thay đổi ghi trong cache.

• Ví dụ các hệ thống CDN nơi nội dung ít thay đổi được lưu cache khi có truy cập đọc, trong khi các bản cập nhật được xử lý qua write-around.

Cache-aside & write-through: Sự kết hợp này hiếm khi được sử dụng trong thực tế vì nó mâu thuẫn trong triết lý thiết kế:

• Cache-aside cho phép ứng dụng chủ động tải dữ liệu từ nguồn khác nhau, mang lại sự linh hoạt và không phụ thuộc hoàn toàn vào cache. Ngược lại, write-through yêu cầu cache tự động đồng bộ dữ liệu xuống database. Nếu cache gặp sự cố, ứng dụng sẽ quay lại truy cập database theo cách của cache-aside, dễ dẫn đến dữ liệu không đồng nhất và làm tăng độ phức tạp khi xử lý.
• Thêm vào đó, khi sử dụng cache-aside, ứng dụng có thể linh hoạt tuỳ chỉnh cách lưu trữ dữ liệu trong cache, điều mà write-through lại không cho phép.

V. Kết luận

Không có chiến lược caching nào hoàn hảo cho mọi trường hợp. Lựa chọn giải pháp phù hợp, bạn cần cân nhắc kỹ lưỡng dựa trên các yếu tố sau:

• Yêu cầu hệ thống: Tính nhất quán dữ liệu, hiệu năng, khả năng mở rộng, và khả năng chịu lỗi của ứng dụng...
• Data Access Pattern: Read-heavy hay write-heavy, hotspot data, đặc điểm, kích thước của data set...
• Các yếu tố khác: Kiến trúc hệ thống hiện tại, độ phức tạp khi triển khai, tài nguyên sẵn có, và chi phí cần đầu tư...

Chỉ khi hiểu rõ yêu cầu hệ thống, kết hợp với việc cân nhắc kỹ lưỡng ưu nhược điểm của từng chiến lược, bạn mới có thể đưa ra lựa chọn tối ưu, đảm bảo hiệu suất và độ tin cậy cho hệ thống.

---

✏️ System Design VN: https://fb.com/groups/systemdesign.vn
📚 Đọc thêm tài liệu khác: https://roninhub.com/tai-lieu
🎬 Youtube: https://youtube.com/@ronin-engineer