Lovable xây dựng dịch vụ thời gian thực để tập trung hóa quyền truy cập dữ liệu

Ngày 9 tháng 11 năm 2026, Lovable cho biết giao diện người dùng của họ đã ngừng sử dụng Firestore sau khi triển khai đầy đủ Lovable Realtime, một dịch vụ tùy chỉnh tập trung hóa việc phân quyền và đạt đỉnh 2,06 triệu lượt đăng ký đồng thời trong giai đoạn đo lường kéo dài 30 ngày.

Việc chuyển đổi đưa các quyết định về quyền truy cập và những trường dữ liệu được hiển thị vào phần phụ trợ Go của Lovable. Với nền tảng xây dựng ứng dụng AI của công ty, dịch vụ này cung cấp một cách kết hợp dữ liệu từ Firestore và Spanner, đồng thời cập nhật chế độ xem của người dùng khi thông tin nền tảng hoặc quyền của người dùng đó thay đổi.

Tập trung hóa quyền truy cập và dữ liệu trực tiếp

Một số phần của Lovable trước đây sử dụng Firestore trên trình duyệt onSnapshot để lắng nghe các cập nhật. Trình duyệt nhận toàn bộ tài liệu, trong khi các quy tắc của Firestore phải phản ánh mô hình phân quyền của API Go. Thiết kế này cũng khiến việc để lộ dữ liệu trở thành một phần của những thay đổi tài liệu thông thường: người thêm một trường có thể quyết định dữ liệu nào được gửi đến trình duyệt của người dùng mà không nhất thiết nhận ra hệ quả đó.

Các quy tắc của Firestore có thể truy vấn dữ liệu Firebase nhưng không thể truy vấn Spanner, gây trở ngại cho việc cập nhật quyền truy cập ảnh hưởng đến các nhóm doanh nghiệp lớn được đồng bộ hóa qua SCIM, một giao thức đồng bộ người dùng và nhóm vào không gian làm việc Lovable. Một giải pháp proxy tạm thời thông qua API Go dành cho khách hàng doanh nghiệp và khách hàng lớn sử dụng lại các bước kiểm tra quyền của API. Giải pháp này cũng mở các kênh lắng nghe Firestore riêng ở phía nguồn cho từng phần phụ thuộc của ứng dụng khách, làm trùng lặp luồng dữ liệu và tiêu tốn dung lượng trong nhóm kết nối dùng chung với các yêu cầu cơ sở dữ liệu thông thường.

Lovable yêu cầu giải pháp thay thế hoạt động được với cả hai cơ sở dữ liệu hiện có, liên tục đánh giá lại quyền truy cập và đóng luồng của người dùng bị thu hồi quyền ngay giữa phiên. Công ty cũng muốn các trường không được phép truy cập bị chặn trước khi bất kỳ dữ liệu nào rời khỏi máy chủ. Theo đánh giá của công ty, các phương án về truyền tải, đồng bộ hóa và tích hợp cơ sở dữ liệu mà họ xem xét không thể đáp ứng đồng thời những yêu cầu đó nếu không cần nhiều công sức tích hợp, thay đổi cơ sở dữ liệu hoặc sao chép dữ liệu sang Postgres.

Dịch vụ Go được xây dựng chạy trên GKE, mở một kết nối WebSocket cho mỗi thẻ trình duyệt và ghép nhiều lượt đăng ký trên cùng kết nối đó. Các luồng thu thập dữ liệu thay đổi chuyển những thay đổi từ Firestore và Spanner qua một cầu nối đến NATS, hệ thống truyền thông điệp của dịch vụ. Những lượt đăng ký phù hợp sẽ tính toán lại chế độ xem, so sánh các giá trị băm xxh3-128 và chỉ gửi các phần chênh lệch khi kết quả đầu ra thay đổi. Một lượt đăng ký duy nhất có thể lấy dữ liệu từ cả hai cơ sở dữ liệu, đồng thời áp dụng khuôn khổ phân quyền của API.

Quyền truy cập được xem như một nguồn dữ liệu phản ứng khác, cho phép các thay đổi về quyền kích hoạt kết quả mới mà không phụ thuộc vào những chỉnh sửa tài liệu thông thường. Lovable cho biết việc chỉ tính toán lại khi các trường liên quan đến quyết định truy cập thay đổi, thay vì mỗi khi tài liệu liên quan được cập nhật, đã giúp giảm khoảng 84% số lần tính toán lại quyền. Dịch vụ có khoảng 40 loại lượt đăng ký do bảy nhóm phụ trách, cùng các giao diện có kiểu dữ liệu xác định, các lượt đăng ký dùng chung ở phía máy chủ và cảnh báo được chuyển đến từng nhóm.

Lưu lượng bóng xác thực quá trình triển khai

Ban đầu, Lovable chạy dịch vụ ở chế độ bóng: giao diện người dùng sử dụng toàn bộ luồng mới nhưng loại bỏ dữ liệu nhận được và tiếp tục hiển thị nội dung từ Firestore. Việc sử dụng lưu lượng và cấu trúc dữ liệu thực tế đã làm lộ ra tình trạng kết nối lại ồ ạt sau các đợt triển khai, lỗi bị phân loại sai và giới hạn kích thước dữ liệu quá thấp so với dữ liệu thực. Sau đó, một cờ tính năng lần lượt tăng tỷ lệ người dùng được cung cấp tính năng từ 1% lên 10%, 50% rồi 100% trong vài ngày. Lovable cho biết quá trình triển khai không gây ra sự cố nào ảnh hưởng đến người dùng và không làm suy giảm các chỉ số được theo dõi.

Do các kết nối WebSocket được duy trì cố định và có thể kéo dài hàng giờ, việc bổ sung các pod không tự động phân bổ lại tải hiện có. Lovable cân bằng tải dựa trên số kết nối, mở rộng quy mô bằng cách xét số kết nối cùng với mức sử dụng CPU và bộ nhớ, đồng thời giới hạn số kết nối trên mỗi pod để hạn chế các đợt kết nối lại ồ ạt. Sau khi kết nối lại, ứng dụng khách gửi dấu vân tay của trạng thái đã lưu trong bộ nhớ đệm, giúp máy chủ xác nhận dữ liệu không thay đổi sau khi kiểm tra lại quyền truy cập, thay vì truyền lại dữ liệu.

Tác giả bài viết cho biết phần cốt lõi mất 40 ngày làm việc trực tiếp để hoàn thành và các tác nhân lập trình đảm nhiệm phần lớn công việc triển khai sau khi kiến trúc cùng các trường hợp ngoại lệ đã được xử lý. Một bộ công cụ tích hợp kết hợp các trình mô phỏng Firestore, Auth và Spanner với máy chủ NATS nhúng cùng các mã thông báo ID thực do trình mô phỏng tạo ra, cho phép các tác nhân kiểm thử những thay đổi trên toàn bộ hệ thống.

Kết quả vận hành thực tế và khả năng hỗ trợ ứng dụng trong tương lai

Trong giai đoạn từ ngày 5 tháng 9 đến ngày 5 tháng 10 năm 2026, Lovable báo cáo có 2,61 tỷ khung dữ liệu và bản vá, không tính các khung điều khiển được tiếp tục gửi sau khi kết nối lại, đồng thời ước tính rằng việc gửi ảnh chụp toàn bộ dữ liệu cho mọi kết quả tính toán sẽ tạo ra 40 TB tải trọng ứng dụng. Việc khử trùng lặp, gửi phần chênh lệch và tái sử dụng dữ liệu khi kết nối lại đã đưa tổng tải trọng thực tế được gửi xuống còn 1,11 TB, giảm ước tính 97% so với mức cơ sở đó. Các số liệu tải trọng không bao gồm phần tiêu tốn của giao thức và quá trình truyền tải.

Lovable đo khoảng thời gian từ lúc ghi dữ liệu vào cơ sở dữ liệu nguồn đến khi khung dữ liệu gửi đi sẵn sàng được truyền là 66 mili giây ở p50 và 249 mili giây ở p99. Các số đo này không bao gồm việc ghi dữ liệu qua socket, thời gian truyền trên mạng và quá trình xử lý của ứng dụng khách, vì vậy không thể hiện toàn bộ thời gian cập nhật mà người dùng cảm nhận được.

Lovable cho biết họ đang tích cực bổ sung các cấu phần nền tảng cho sự kiện miền, dành cho những trường hợp bên tiêu thụ cần được thông báo khi có sự việc xảy ra thay vì chỉ nhận ảnh chụp dữ liệu; dịch vụ này cũng có thể trở thành một tính năng trong các ứng dụng được xây dựng bằng Lovable trong tương lai. Phần mở rộng như vậy sẽ mang các quyền được kiểm soát ở phía máy chủ và chế độ xem dữ liệu trực tiếp đến những ứng dụng do khách hàng tạo. Hệ thống hiện tại đã cung cấp cho các nhóm của Lovable một nền tảng chung để cộng tác sâu rộng hơn khi hạ tầng dữ liệu của họ phát triển.