Notification System

When any part of the platform — bookings, draws, license renewals, ranking jobs — needs to reach a user, it raises a notification event rather than calling an email or SMS API directly. The hub picks the right channel mix (Email notifications via ACS/SendGrid, SMS notifications via ACS/46elks, Push notifications via FCM) based on the event type and the user's notification preferences, including chosen channels, frequency caps, and quiet hours.

Template resolution walks a four-key lookup: tenant, channel, locale, event. A custom template at the federation layer wins; otherwise the platform default applies. Notification templates are Mustache-rendered, so editors can drop in {{player.name}}, {{match.startsAt}}, or {{competition.title}} without touching code, and previews render against sample data before going live. Each tenant maintains its own template library per language, satisfying the multi-language obligation across 43+ FIPJP locales.

Dispatch is idempotent on the tuple (booking or event id, channel, recipient): if a worker retries, the recipient does not get duplicates. Every send is written to the notification delivery log with status (queued, sent, delivered, bounced, opened where allowed), so support staff can audit a single user's history end-to-end. Competition-specific notifications fire on draw published, next match imminent, and final results; license renewal reminders ramp up at T-60, T-30, T-7, and T-0 days; ranking change notifications fire after the periodic recompute when a player crosses a configured threshold.

For mass communication the same engine powers federation circular distribution — bulk sends to filtered member segments — with per-channel opt-out and unsubscribe links injected automatically. The hub respects the shared suppression list with the newsletter engine, so a hard bounce or complaint anywhere in the platform protects the user across both transactional and marketing flows.