Trong kỷ nguyên của AI và các ứng dụng cộng tác thời gian thực, dữ liệu không chỉ cần “đủ” mà còn phải “siêu nhanh”. Khi hệ thống đạt đến quy mô toàn cầu (at scale), những kiến trúc truyền thống từng vận hành rất tốt bỗng chốc trở thành nút thắt cổ chai, ngốn hàng triệu USD chi phí hạ tầng và kéo lùi trải nghiệm người dùng.
Bài viết này sẽ mổ xẻ hành trình tái cấu trúc hạ tầng mang tính kinh điển của hai gã khổng lồ công nghệ: Figma (với bài toán nâng cấp Data Pipeline từ vài ngày xuống vài mươi phút) và Databricks (với giải pháp tối ưu hệ thống Rate Limiting đạt độ trễ siêu thấp). Đây là những bài học xương máu về tư duy thiết kế hệ thống phân tán mà bất kỳ kỹ sư hay kiến trúc sư phần mềm nào cũng nên tham khảo.
PHẦN 1: Figma Và Cuộc Cách Mạng Thay Máu Data Pipeline (Từ 30 Giờ Xuống 30 Phút)
1. Thảm họa từ câu lệnh “SELECT *” truyền thống
Ban đầu, Figma sử dụng mô hình đồng bộ dữ liệu cốt lõi rất phổ biến: Full-table sync hàng ngày. Hệ thống sẽ chạy các câu lệnh quét toàn bộ bảng (SELECT *) từ các database Replica của Amazon RDS (PostgreSQL) rồi ghi đè vào kho dữ liệu (Data Warehouse) Snowflake.
Khi quy mô dữ liệu của Figma phình to gấp 10 lần, kiến trúc này lập tức sụp đổ:
Độ trễ dữ liệu (Data Freshness) chạm mốc 30+ tiếng, khiến các báo cáo kinh doanh và phân tích vận hành luôn trong tình trạng “đi sau thời đại”.
Chi phí đắt đỏ: Figma phải duy trì các cụm DB Replica cấu hình khủng chỉ để phục vụ việc export dữ liệu, tiêu tốn hàng triệu USD mỗi năm.
2. Giải pháp: Kiến trúc CDC kết hợp Incremental Merge trên Snowflake
Figma quyết định đập đi xây lại hệ thống, chuyển dịch hoàn toàn sang kiến trúc hướng sự kiện (Event-Driven) bằng công nghệ CDC (Change Data Capture). Luồng xử lý chi tiết bao gồm 4 bước tối ưu:
[ PostgreSQL ] ──(WAL Logs)──► [ CDC Engine ] ──(Stream)──► [ Apache Kafka ]
Bước 1: Khởi tạo vùng đệm (Raw Ingestion): Dữ liệu từ Kafka được nạp liên tục vào Raw CDC Staging Table dưới dạng file thô (Avro/JSON). Mỗi dòng chứa metadata quan trọng:
__op(hành động: Tạo, Sửa, Xóa) và__source_ts_ms(timestamp từ nguồn).Bước 2: Theo dõi thay đổi (Snowflake Streams): Figma tận dụng tính năng Snowflake Streams gắn trên bảng Staging để tự động ghi nhận các dòng dữ liệu mới được thêm vào kể từ lần xử lý trước đó.
Bước 3: Khử trùng lặp cục bộ (Deduplication) trước khi Merge: Để tránh việc quét và ghi đè lặp đi lặp lại trên các phân vùng ổ đĩa (Micro-partitions) gây tốn chi phí tính toán, hệ thống sử dụng hàm cửa sổ (
ROW_NUMBER() OVER (...)) để chỉ giữ lại duy nhất 1 sự kiện mới nhất của mỗi bản ghi trong chu kỳ.Bước 4: Thực thi câu lệnh
MERGEtối ưu: Hệ thống áp dụng lệnhMERGE INTOđịnh kỳ (3 tiếng/lần cho bảng thường, 30 phút/lần cho bảng Billing) để phân tách logic: Xóa dữ liệu (Hard/Soft Delete), Cập nhật (Updates) khi trùng ID, hoặc Thêm mới (Inserts).
3. Vũ khí bí mật: Quy trình “Trust But Verify”
Thử thách lớn nhất của CDC là các lỗi ngầm (Silent Failures) – pipeline không sập nhưng dữ liệu bị sai lệch do mất event. Figma đã giải quyết bằng một hệ thống Validation Workflow độc lập: Định kỳ mỗi tuần, hệ thống tự động sao chép một bản độc lập từ PostgreSQL, chạy so sánh từng ô dữ liệu (Cell-by-cell) với Snowflake để tìm sai lệch, giúp phát hiện sự cố ngay từ môi trường Staging.
Kết quả: Độ trễ dữ liệu giảm từ 30+ giờ xuống dưới 3 giờ (riêng billing là 30 phút), tiết kiệm hàng triệu USD chi phí hạ tầng do loại bỏ được các cụm RDS Replica cồng kềnh.
PHẦN 2: Databricks Và Nghệ Thuật Tối Ưu Hệ Thống Rate Limiting Quy Mô Siêu Lớn
Nếu Figma giải quyết bài toán lưu trữ và đồng bộ, thì Databricks lại đối mặt với bài toán xử lý traffic thời gian thực khi cung cấp các dịch vụ AI (Real-time Model Serving).
1. Nút thắt cổ chai mang tên Redis
Kiến trúc cũ của Databricks sử dụng mô hình tiêu chuẩn: Envoy Proxy → Rate Limiting Service → Redis.
Khi lượng request tăng đột biến, mô hình này gặp hạn chế nghiêm trọng: phải trải qua 2 chặng mạng (network hops) từ Gateway đến Service và từ Service đến Redis. Độ trễ ở phân vị P99 lên tới 10–20 ms và cụm Redis tập trung trở thành điểm nghẽn đơn độc (Single Point of Failure) nguy hiểm.
2. Sự trỗi dậy của Dicer và In-Memory Counters
Để đưa độ trễ về mức gần như bằng 0, Databricks đã đưa ra một quyết định táo bạo: xóa bỏ hoàn toàn Redis, đưa bộ đếm lên lưu trữ trực tiếp trên RAM (In-Memory) của các server thành viên. Để làm được điều này, họ phát triển Dicer - hạ tầng phân mảnh tự động (Auto-sharding).
Định tuyến dựa trên trạng thái (Stateful Routing): Dicer sử dụng thuật toán Consistent Hashing dựa trên ID tài khoản. Khi Envoy gửi báo cáo, Dicer tính mã băm và định tuyến chính xác đến duy nhất một Server instance đang giữ bộ đếm của tài khoản đó trong RAM.
Gom cụm bất đồng bộ (Asynchronous Batching): Thay vì gửi request đồng bộ cho từng click, Envoy tự đưa ra quyết định cục bộ và gom cụm số liệu lại. Cứ mỗi 100 ms, một tiến trình nền sẽ gửi một mẻ báo cáo lớn (Batch report) trực tiếp đến server đích nhờ thuật toán Dicer chạy ngay tại chỗ.
3. Nghệ thuật đánh đổi: Chấp nhận sai số 5% và “Số dư âm”
Xử lý bất đồng bộ đồng nghĩa với việc chấp nhận hệ thống bị lọt lưới (overshoot) khoảng 5% traffic trong khoảng thời gian 100 ms giữa các kỳ báo cáo. Databricks đã khắc phục bằng cơ chế Negative-Balance Memory (Số dư âm) của thuật toán Token Bucket:
Nếu trong 100ms, khách hàng “nã” lố 50 request, khi nhận batch báo cáo, Server sẽ trừ thẳng vào Token Bucket khiến số dư bị âm 50. Server sẽ lập tức trả về lệnh chặn (
rejectTilTimestamp) ở chu kỳ tiếp theo cho đến khi lượng token hồi phục về mức dương. Khách hàng phải “trả giá” ở chu kỳ sau cho lượng quota đã ứng trước.
Kết quả: Độ trễ đuôi (tail latency) giảm xuống gần 10 lần, hệ thống hoạt động cực kỳ ổn định bất chấp các đợt càn quét của bão traffic AI.
TỔNG KẾT: Những Tư Duy Thiết Kế Hệ Thống Kinh Điển
Qua hai case-study của Figma và Databricks, chúng ta có thể đúc kết bảng so sánh tư duy chuyển dịch kiến trúc như sau:
Tiêu chí
Tư duy cũ (Trực quan nhưng Khó Scale)
Tư duy mới (Phân tán và Tối ưu hiệu năng)
Xử lý dữ liệu
Quét toàn bộ (Full-table sync / SELECT *)
Xử lý lũy tiến (CDC + Incremental Merge)
Giao tiếp mạng
Đồng bộ (Synchronous - Chờ đợi phản hồi)
Bất đồng bộ (Asynchronous Batching / Streaming)
Lưu trữ trạng thái
Tập trung (Centralized - Giống như Redis)
Phân mảnh cục bộ (Sharded In-Memory / Dicer)
Độ chính xác
Đòi hỏi chính xác tuyệt đối ở mọi chặng
Chấp nhận sai số nhỏ có kiểm soát để đổi hiệu năng
Lời kết: Thiết kế hệ thống phân tán ở quy mô lớn không phải là câu chuyện tìm ra một công cụ hoàn hảo, mà là nghệ thuật của sự đánh đổi (Trade-offs). Figma chấp nhận xây dựng thêm hệ thống xác thực phức tạp để đổi lấy kiến trúc CDC tiết kiệm chi phí; Databricks chấp nhận 5% sai số kiểm soát được để đổi lấy độ trễ tối ưu cho mô hình AI.
Hi vọng bài viết này mang lại những góc nhìn giá trị cho bạn trong việc thiết kế và tối ưu hạ tầng ứng dụng của mình!
0 Nhận xét