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.
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.