G-HUB

Đề bài

G-HUB khởi đầu là một CRM và liên tục từ chối dừng lại ở đó. Sale muốn deal và pipeline, chăm sóc khách muốn mọi kênh về chung một hộp thư, marketing muốn chiến dịch và chuỗi email, nhân sự muốn chấm công và onboarding, đào tạo muốn một chỗ để khoá học. Mỗi cái trong đó tự nó đã là một sản phẩm. Làm năm sản phẩm là cách một đội nhỏ tự giết mình, nên việc phải làm là dựng một hệ thống đủ để năm đội đó sống trong đấy.

Cách làm

Một backend Express trên MongoDB, một React SPA, một app Flutter — và chia domain thành module chứ không chia thành service. Tới giờ là 215 model Mongoose sau 87 nhóm route, cùng 40 module tính năng ở client: CRM, deal, đa kênh, broadcast, chuỗi email, HRM, chấm công, academy, kho, chatbot, tích hợp quảng cáo, dashboard điều hành.

Chọn modular monolith là quyết định có chủ đích. Đội nhỏ, mà các domain nói chuyện với nhau liên tục — một deal chạm tới khách hàng, một hội thoại, một chiến dịch và một hoá đơn. Xé nhỏ thành service ở giai đoạn này chỉ mua thêm transaction phân tán, không mua được gì khác.

Chỗ khó

Đa kênh mới là nơi tốn công nhất. Zalo, SMS, Viber, TikTok và widget web mỗi thứ nói một phương ngữ, đến không đúng thứ tự, và hỏng theo những cách khác nhau. Mọi tin nhắn đi vào đều chuẩn hoá về một model hội thoại, còn mọi tin đi ra đều qua một hàng đợi biết giới hạn tần suất và cách retry của từng kênh. BullMQ trên Redis đẩy phần việc đó ra khỏi luồng request; Socket.IO với Redis adapter bắn kết quả tới đúng tiến trình đang giữ socket của người dùng.

Phân quyền là chỗ khó thứ hai, âm ỉ hơn. Với chừng này module, kiểm tra quyền rải rác trong controller sẽ mục trong vài tuần. CASL gom hết về một chỗ định nghĩa ability mà cả client lẫn server cùng đọc, nên giao diện ẩn đúng thứ mà API cũng sẽ từ chối.

Nếu làm lại

Tôi sẽ đưa hàng đợi vào từ tuần đầu thay vì tháng thứ ba. Những tính năng cuối cùng đều cần tới nó — broadcast, chuỗi email, import, gọi AI — đều khởi đầu là handler đồng bộ, và cái nào cũng phải tháo ra làm lại về sau khi tải lên.