Platform — Góc nhìn end-user
Platform chạy ở hậu trường, người dùng không bấm nút "Platform" bao giờ. Nhưng nó là lý do nhiều trải nghiệm quen thuộc hoạt động đúng. Dưới đây là cách nó hiện diện qua mắt người dùng.
1. Nhận thông báo đúng lúc
"Tôi vừa đăng ký tài khoản và lập tức nhận được email chào mừng."
Khi người dùng làm một hành động (đăng ký, nộp incident, đổi cấu hình…), hệ thống không bắt họ chờ email gửi xong mới phản hồi. Thao tác được lưu ngay, còn việc gửi email diễn ra ngay sau đó ở hậu trường. Người dùng thấy "tức thì" nhưng thực ra email đi qua một dây chuyền xử lý.
2. Không bị spam, không nhận trùng
"Mạng tôi chập chờn, tôi bấm gửi 2 lần — nhưng chỉ nhận đúng 1 email."
Đây chính là giá trị của chống trùng lặp. Dù thao tác bị thử lại nhiều lần (do mạng, do hệ thống retry), người dùng vẫn chỉ nhận một thông báo. Họ không bao giờ thấy 2 email giống hệt nhau cho cùng một sự việc.
3. Xem được lịch sử thay đổi (timeline)
"Tôi mở một hồ sơ và thấy danh sách: ai sửa gì, lúc nào."
Mỗi khi một entity (tài khoản, hóa đơn, hồ sơ…) thay đổi, hệ thống ghi một dòng vào lịch sử. Người dùng/admin mở entity sẽ thấy một timeline gọn gàng — không có dòng trùng, kể cả khi thao tác gốc bị xử lý lại.
4. Quản trị viên bật/tắt loại thông báo
"Trong phần Settings, tôi tắt loại email 'cập nhật hồ sơ nhân viên' cho đơn vị của mình."
Admin của mỗi BusinessUnit có thể cấu hình loại thông báo nào được gửi, gửi cho ai. Platform tôn trọng cấu hình này: bước Scheduler trong pipeline sẽ kiểm tra Notification Settings trước khi thực sự gửi.
5. Dữ liệu lớn và truy vết message
"Event vẫn được xử lý dù payload lớn, và support lần được message về đúng invoice/account."
Platform có thể chuyển payload event lớn sang Blob, giữ BlobRef trong message queue. Khi notification được tạo, SourceKey của nguồn nghiệp vụ được giữ ở message để đối chiếu job, người nhận, kênh và trạng thái gửi. Đây là thông tin vận hành; giao diện end-user vẫn chỉ hiển thị kết quả cuối cùng.
Ví dụ thực tế: Email invoice bị retry vẫn được support tìm trong cùng nhóm
SourceKey, thay vì phải dò theo từng lần gửi hoặc theo một khóa ngẫu nhiên.
Tóm lại với end-user
| Trải nghiệm | Nhờ phần nào của Platform |
|---|---|
| Thao tác phản hồi tức thì, email tới sau | Pipeline gửi bất đồng bộ (async) |
| Không nhận thông báo trùng | Deterministic key + chống dual-path |
| Timeline lịch sử sạch, không trùng | Entity History + upsert theo khóa tất định |
| Bật/tắt loại thông báo theo đơn vị | Notification Settings ở bước Scheduler |
Muốn biết "bên dưới" làm thế nào để có được những điều trên? Đọc tiếp Khái niệm cốt lõi.