2024-01-21 08:15 — 2 phút đọc

Push notification In-App channel

#push#notification#system#architecture#howto#mqtt


Bài viết về hệ thống Push notification là phần thiết kế tổng quan.

Bài viết này nói chi tiết về In-App channel và làm cách VETC đang ứng dụng vào hệ thống payment của họ.


Thông tin cơ bản

Requirements của các team marketing và payment:

  • Có một hệ thông chung để gửi notification In-App cho người dùng cuối
  • Tránh việc sử dụng firebase có tốc độ rất chậm trong thanh toán hoặc tạo các popup ngay trên ứng dụng
  • Có thể gửi notification In-App cho người dùng ngay khi họ thực hiện các giao dịch trên ứng dụng

Thiết kế

In-App channel

Các thành phần

  1. Client Application: là các bên sử dụng hệ thống.
  2. Publisher(In-App): là các service nhận messages từ client application
  3. Router(RabbitMQ): nhận messages từ publisher
  4. Consumer(In-App): lắng nghe router và gưi messages tới MQTT Broker
  5. MQTT Broker: gửi tới messages các Mobile App, Web App, …

Các bước thực hiện

  • Gửi Message: Ở bước này thì các template và token đã được đăng ký trước đó và được thống nhất bởi các team.
  • Publisher: Nhận thông tin Messages => validated, formatted, authenticated, và priority dựa trên các cài đặt sẵn có của người dùng.
  • Publisher: Dựa theo template type, priority mà các message sẽ được gửi tới các queue khác nhau.
  • Consumer: Nhận messages từ các queue khác nhau và publish tới MQTT Broker.
  • MQTT Broker: Các message sẽ được gửi tới các Mobile App, Web App, …

Các kịch bản

  • Kịch bản 1: Các message gửi từ team Marketing sẽ được cấp user có template type gắn với các template mà họ đã khai báo trước đó và đã có sự thống nhất với team mobile. Các message này sẽ được gửi tới các queue có priority thấp hơn các message từ team Payment. Nó sẽ được gửi vào các RabbitMQ có rate limit thấp hơn. Chúng sẽ được lắng nghe ở các consumer và gửi tới MQTT Broker. App mobile sẽ dựa theo template type và priority để hiển thị popup, thông báo marketing tương ứng cho người dùng cuối.

  • Kịch bản 2: Message được gửi từ team Payment cũng giống như trên nhưng với priority cao hơn. Nó sẽ được ưu tiên gửi trực tiếp vào RabbitMQ không có rate limit. Các MQTT Broker và mobile cũng sẽ ưu tiên hiển thị các thông báo này trước.

Kết luận

Việc chia channel In-App cho các team marketing và payment giúp cho việc quản lý các message dễ dàng, bảo mật và kiểm soát chất lượng message trước khi gửi hàng triệu tin cho người dùng cuối. Việc này tránh được việc sử dụng firebase có tốc độ rất chậm và không phù hợp trong các giao dịch thanh toán.

Tham khảo


aitu avatar

Hi! Tôi là Tuyên — Hiện tại tôi đang làm Software Architect, Senior developer tại một công ty nhỏ ở Hà Nội. Tôi cảm thấy thích thú, đam mê, yêu thích với việc viết lách và chia sẻ những kiến thức mà tôi biết. Hãy đọc nhiều hơn tại blogs và tới about để biết thêm về tôi nhé.