Product EngineeringFeaturesNotification SystemBackend

Data Model

Database schema and core tables used by the Notification System backend.

👤 Development Team📅 Updated: Mar 16, 2026📁 Services🏷️ notifications🏷️ backend🏷️ data-model🏷️ schema

Data Model

The Notification System relies on a set of dedicated tables to model:

  • Notification types and configuration
  • User and lab preferences
  • Individual notification instances
  • Read/unread activity
  • FCM device tokens

Entity-Relationship Diagram

The following ER diagram (also shown in the main Notification System overview) captures the core tables:

Table Overview

  • NotificationTypeMaster

    • Catalogue of all notification types supported by the system.
    • Fields capture category, name, description, and default message parameters.
  • LabNotificationTypes

    • Lab-level configuration for each notification type.
    • Controls whether a type is enabled/disabled and lab-specific message parameters.
  • UserNotificationPreferences

    • Per-user overrides on top of lab defaults.
    • Used to honour user-level opt-in/opt-out and preference management.
  • Notifications

    • Stores each generated notification instance (who it is about, payload, when it was created).
    • Links back to the lab-level notification type.
  • NotificationActivity

    • Tracks per-recipient activity (e.g. when a notification was read).
    • Used to derive read/unread status and audit trails.
  • FcmDevices

    • Maps FCM device tokens to lab users/doctors and session keys.
    • Stores topics subscribed for each device and last activity time.

These tables underpin the APIs described in the API Reference.

On this page