Build Web App Hẹn Hò Open-Source: Thuật Toán Ghép Đôi Tối Ưu & Bảo Mật Dữ Liệu 2026
Đăng bởi hong_ngoc • 14:17 21/09/2026
"Làm sao để tự code một nền tảng kết nối mà không tốn tiền server hằng tháng?" - câu hỏi này cứ văng vẳng trong đầu mình mãi cho đến khi quyết định ngồi xuống xắn tay áo viết lại từ đầu.
Thật ra, phần lớn các ứng dụng hiện nay đều bóp nghẹt người dùng bằng paywall đắt đỏ. Là dân kỹ thuật sinh hoạt tại ZolaChat.Com, mình thấy tội gì phải chịu cảnh đó trong khi hoàn toàn có thể tự dựng một hệ thống riêng. Bài toán đặt ra là làm sao tối ưu chi phí hạ tầng tiệm cận 0 đồng nhưng vẫn mượt mà.
Về phần tech stack, thay vì chọn mấy ông lớn tốn kém, mình quất ngay Next.js cho frontend để tối ưu tải trang, kết hợp Node.js hoặc Go cho backend xử lý request nặng. Riêng phần database, bắt buộc phải dùng PostgreSQL đi kèm extension PostGIS. Hồi trước mình từng dại dột dùng công thức Haversine tính bằng CPU ở tầng app cho các ca tìm kiếm hồ sơ kết bạn Biên Hòa trong bán kính 10km, kết quả là cứ data lớn một chút là server hăng hái lăn ra thở dốc. Chuyển sang dùng Spatial Index (GiST) của PostGIS với câu lệnh query tối ưu không gian:
SELECT id, username, ST_Distance(location, ST_MakePoint(longitude, latitude)::geography) / 1000 AS distance_km
FROM user_profiles
WHERE ST_DWithin(location, ST_MakePoint(longitude, latitude)::geography, 10000)
ORDER BY distance_km ASC
LIMIT 20;
Chỉ cần vậy là mọi thứ chạy phăng phăng, không còn độ trễ khó chịu.
Một vấn đề đau đầu nữa là bảo mật thông tin. Người dùng thường tìm kiếm những từ khóa rất đời như tìm bạn gái già có số điện thoại, nhưng nếu show raw phone number ra thì sớm muộn gì hệ thống cũng ngập rác spam. Giải pháp ở đây là áp dụng mã hóa AES-256 ở database và dùng cơ chế Virtual Proxy Contact, tuyệt đối không lưu dữ liệu định danh cá nhân dạng plain-text trên client side.
Còn về tính năng ghép đôi với người lạ hay random match, thay vì query database truyền thống gây nghẽn, mình dùng Redis Data Structures với cấu trúc List và Sorted Set thông qua background worker lắng nghe queue để bắt cặp ngẫu nhiên trong chưa đầy 50ms.
Mà thôi, nói vậy hơi dài dòng, cốt lõi vẫn là cách anh em cân đối giữa tính năng và bài toán vận hành thực tế trên cộng đồng ZolaChat.Com.
Anh em trong ngành nghĩ sao về kiến trúc hệ thống này, nếu bổ sung tính năng AI tự động phát hiện tin nhắn lừa đảo thì nên chọn tích hợp LLM cọ xát trực tiếp hay dùng Filter Model mỏng ở Edge Worker?
Bình luận (6)
linh_kute
Đúng ý mình ghê, giờ mấy app hẹn hò toàn hút máu người dùng thôi. Build open-source thế này anh em cùng đóng góp thì tuyệt vời quá!
khanh_trang
Bác ơi, thuật toán ghép đôi bác định dùng mô hình gì thế? Hóng phần chia sẻ chi tiết kỹ thuật của bác nha, chủ đề này cuốn thật sự.
bao_vy
Ủng hộ dự án của bác chủ thớt! Phần bảo mật dữ liệu người dùng là quan trọng nhất, hy vọng bác sẽ làm nó thật chỉn chu. 😊
tu_nhi
Dự án tâm huyết quá, em cũng đang tập tành học fullstack. Có link repo chưa bác cho em xin vào học hỏi với ạ! ❤️
diem_quynh
Chuẩn bác ơi, app nào giờ cũng thu phí tính năng cơ bản chán lắm. Mong chờ phiên bản open-source của bác sớm ra mắt nhé! 👍
quynh_anh
Chủ thớt chia sẻ đúng cái mình đang tò mò luôn, dạo này mấy ứng dụng hẹn hò thương mại hóa quá đà thật!
Cho mình hỏi sâu chút về phần tối ưu chi phí: Nếu dùng hạ tầng tiệm cận 0 đồng (như server free-tier), bác xử lý bài toán truy vấn vị trí địa lý (Geospatial queries) và tính điểm tương thích realtime thế nào để không bị nghẽn RAM khi scale lượng user lớn?
Rất hóng phần giải thích kỹ hơn của bác ở bài tiếp theo nhé!
