NG Chat Backend
Xác thực, credit và lịch sử chat cho NG Assistant
Kiến trúc backend cho chatbot: cổng Go lo xác thực, giới hạn tốc độ và trừ credit; FastAPI chỉ lo trả lời và lưu lịch sử; Supabase Postgres chia schema theo dịch vụ. Khách chưa đăng ký vẫn chat được với hạn mức.
- Vai trò
- Nhà sáng lập – kiến trúc hệ thống, thiết kế cơ sở dữ liệu
- Năm
- 2026
- Trạng thái
- Đang xây dựng
Mã nguồn thuộc tổ chức ngaiplatform trên GitHub (riêng tư).
01Ý tưởng
Vấn đề
Chatbot phục vụ cả người đã đăng ký, khách trên web và người nhắn qua Facebook, Zalo, Telegram – cần một cách tính hạn mức công bằng, không bị lạm dụng, không trừ trùng.
Phát hiện
Mọi người chat đều là một 'account', dù có đăng ký hay không; đăng ký chỉ nâng gói, không làm mất lịch sử.
Giải pháp
Bảng accounts thống nhất ba loại người dùng, ví credit theo ngày cộng số dư, sổ cái chống trừ trùng theo request_id, hàm SQL trừ/hoàn credit an toàn khi chạy đồng thời.
Dành cho
- Người dùng NG Assistant
- Đội phát triển NG
Mục tiêu
- Khách: 10 credit/ngày; đã đăng ký: 50; Pro: 1.000.
- Mỗi dịch vụ chỉ thấy dữ liệu của mình.
- Không trừ âm, không trừ trùng.
02Tính năng
- 01
Tài khoản thống nhất
registered, guest (đăng nhập ẩn danh), channel (Facebook, Zalo, Telegram) trong một bảng.
- 02
Ví và sổ cái credit
Hạn mức theo ngày Việt Nam + số dư mua thêm; giá theo loại tin: chữ 1, ảnh 3, video 10.
- 03
Phân quyền theo dịch vụ
svc_gateway chỉ dùng schema core, svc_chat chỉ dùng schema chat; frontend không truy cập trực tiếp.
- 04
Lịch sử chat
Hội thoại, tin nhắn, tệp đính kèm trong bucket riêng tư; tin mới tự đẩy hội thoại lên đầu.
03Thiết kế & quyết định
Go cho cổng, Python cho AI
Vì sao: Go nhẹ, chịu nhiều kết nối đồng thời cho xác thực và giới hạn; thư viện AI gần như đều ở Python.
Một database, nhiều schema
Vì sao: Lịch sử chat cần khóa ngoại tới tài khoản; chung database nhưng tách schema và tài khoản database cho từng dịch vụ.
Tách theo môi trường, không theo dịch vụ
Vì sao: Hai project Supabase: dev và prod; nhánh develop triển khai dev, nhánh main triển khai prod.
04Kiến trúc
01
Kênh vào
- Web/App (JWT Supabase), webhook Facebook/Zalo/Telegram
02
Cổng Go
- Xác thực, giới hạn tốc độ (Redis), trừ credit, cấp request_id
03
FastAPI
- Chỉ trả lời và lưu lịch sử – không ra internet
04
Supabase
- auth · core · chat · storage
05Công nghệ
Dịch vụ
- Go
- Python · FastAPI
- Redis
Dữ liệu
- Supabase Postgres
- PL/pgSQL
- Supabase Auth (anonymous, email, Google)
- Supabase Storage
Hạ tầng
- Google Cloud Run
- Cloud SQL (so sánh)
- Vercel
- Cloudflare
06Nghiên cứu
Node.js hay Go
API nghiệp vụ hợp với TypeScript dùng chung kiểu với frontend; phần IoT và cổng nhiều kết nối hợp với Go; AI ở Python.
Lưu dữ liệu cảm biến
Cloud SQL không hỗ trợ TimescaleDB – dùng bảng chia partition theo thời gian, đẩy sang BigQuery khi cần phân tích lớn.
Dữ liệu trong nước
Nghị định 53/2022 và Luật 91/2025 có quy định về lưu và chuyển dữ liệu người dùng – cần tư vấn pháp lý; Supabase tự cài được trên cloud Việt Nam nếu bắt buộc.
07Kết quả
- bảng trong 2 schema
- 11
- hàm SQL nghiệp vụ
- 4
- request đồng thời → đúng 10 lượt được trừ
- 30 → 10
- lần trừ trùng khi gọi lại
- 0
- Kiểm thử trên PostgreSQL thật: hạn mức ngày, sang ngày mới, hoàn credit, khách → đăng ký giữ lịch sử, phân quyền hai dịch vụ.
08Demo & hình ảnh
Video demo đang được chuẩn bị
09Bài học
Bài học
- “Chống trừ trùng phải nằm trong database (request_id duy nhất, khóa dòng ví), không thể tin vào phía client.”
- “Thiết kế dữ liệu đúng từ đầu tiết kiệm nhiều hơn mọi tối ưu sau này.”
Bước tiếp theo
- Viết cổng Go và dịch vụ FastAPI.
- Kênh Zalo OA và Telegram bot.
- Thanh toán mua credit.