[Series Hệ thống chịu tải cao] Bài 1: Đừng dùng Kafka/ES chỉ vì nó "ngầu" – Tư duy đúng về bài toán Scale

Chào anh em! Trong giới Backend, có một hội chứng tạm gọi là "Hội chứng cuồng Tool". Thấy dự án nào cũng đòi đắp Kafka cho nó "Event-driven", thấy search nào cũng phải có Elasticsearch (ES) cho nó "Pro". Nhưng thực tế, việc đưa những "khẩu súng lớn" (Big Guns) này vào hệ thống mà không hiểu rõ tại sao sẽ giống như việc dùng đại bác để bắn chim sẻ: Vừa tốn kém, vừa khó bảo trì.

Hôm nay, hãy cùng mình phân tích xem khi nào thì hệ thống của bạn thực sự cần đến bộ đôi quyền lực này.

1. Nỗi đau mang tên "Nghẽn cổ chai" (The Bottleneck)

Hãy tưởng tượng một kịch bản quen thuộc: Bạn đang làm hệ thống quản lý vé Metro (AFC). Vào giờ cao điểm, hàng vạn hành khách quẹt thẻ cùng lúc.

• Cách truyền thống: Mỗi lần quẹt thẻ -> Gọi API -> Chờ Database (SQL) ghi xong -> Trả về kết quả "Mở cổng".
• Vấn đề: Khi lượng người quá lớn, Database bắt đầu "thở dốc". Những tác vụ phụ như: Gửi thông báo về App, cập nhật báo cáo doanh thu, đẩy dữ liệu sang bên Signal... vô tình làm chậm quá trình quan trọng nhất là "Mở cổng cho khách đi".

Key Takeaway: Nếu hệ thống của bạn đang bị chậm vì những tác vụ "ăn theo" (side-effects) hoặc Database không chịu nổi nhiệt khi Write/Read quá nhiều, đó là lúc cần đến Kafka và ES.

2. Khi nào cần Kafka? (Cơ chế "Mua thời gian")

Kafka không đơn thuần là một cái Message Queue. Hãy coi nó là một hệ thống lưu trữ sự kiện (Event Store) bền bỉ. Bạn cần Kafka khi:

Tách rời các Service (Decoupling): Service Cổng chỉ cần đẩy một sự kiện "Khách đã quẹt thẻ" vào Kafka rồi xong việc. Việc còn lại của Service Thông báo hay Service Kế toán là tự vào Kafka mà "nhặt" dữ liệu về xử lý. Thằng này chết không ảnh hưởng đến thằng kia.

Hứng "Sóng thần" dữ liệu (Buffering): Khi lượng quẹt thẻ tăng đột biến, Kafka đóng vai trò như một cái hồ chứa nước khổng lồ. Dữ liệu đổ vào rất nhanh, các service phía sau có thể thong thả lấy ra xử lý dần theo khả năng của chúng, tránh việc sập toàn bộ hệ thống.

3. Khi nào cần Elasticsearch? (Cơ chế "Tìm kim đáy bể")

Rất nhiều anh em lầm tưởng ES chỉ để làm ô Search. Thực tế, ES mạnh nhất ở khả năng Phân tích dữ liệu lớn (Analytics). Bạn cần ES khi:

Tìm kiếm phức tạp: Khi bạn cần search theo kiểu: "Tìm tất cả hành khách quẹt thẻ tại ga Bến Thành, dùng thẻ loại X, trong khoảng từ 7h-9h sáng". Làm việc này trên SQL với hàng triệu bản ghi sẽ là một cơn ác mộng về Performance.

Tách biệt Read/Write (CQRS): Database chính (PostgreSQL/MySQL) chỉ để ghi dữ liệu giao dịch cho an toàn. Toàn bộ dữ liệu để tra cứu, vẽ biểu đồ, thống kê sẽ được đồng bộ sang ES. Khi đó, sếp có chạy báo cáo nặng đến đâu cũng không làm chậm quá trình quẹt thẻ của khách.

4. Cái giá phải trả (The Trade-offs)

Làm hệ thống chịu tải cao không có "bữa trưa miễn phí". Khi đưa Kafka/ES vào, bạn phải đối mặt với:

Tính nhất quán sau (Eventual Consistency): Khách quẹt thẻ xong, 0.5 giây sau dữ liệu mới hiện lên Dashboard. Bạn có chấp nhận được độ trễ này không?

Độ phức tạp: Bạn phải quản lý thêm Cluster, Monitoring, Backup... Nếu team chỉ có 2 người và lượng User thấp, hãy cân nhắc kỹ!

Tạm kết

Kafka và Elasticsearch là những công cụ tuyệt vời để giải quyết bài toán Scale (Mở rộng) và Availability (Sẵn sàng). Nhưng hãy bắt đầu bằng việc hiểu rõ "nỗi đau" của hệ thống hiện tại trước khi quyết định xuống tay cài đặt.

Ở bài tiếp theo (Bài 2), mình sẽ cùng anh em đi sâu vào "nội tạng" của Kafka. Tại sao nó lại nhanh đến mức vô lý như vậy? Chúng ta sẽ cùng mổ xẻ cơ chế lưu trữ của nó nhé.

Hệ thống của bạn đã bao giờ gặp tình trạng sập Database vì quá tải chưa? Bạn đã giải quyết nó như thế nào? Cùng chia sẻ để anh em học hỏi nhé!