Notification Preference Service
Component Detail
Description
Business logic layer for reading, updating, and enforcing notification opt-out preferences per user and scenario type. Acts as the authoritative gate consulted by the trigger engine before any notification is dispatched.
notification-preference-service
Summaries
The Notification Preference Service is the critical trust and compliance layer between the business and its users. By ensuring no notification is dispatched to a user who has opted out of a specific scenario, this component protects user trust, reduces unsubscribe rates, and mitigates potential regulatory exposure around unsolicited communications. A missed opt-out is not just a user experience failure — it risks brand damage and, in markets with GDPR or similar regulations, compliance liability. This service acts as the authoritative gate that enforces user consent at the moment of dispatch, protecting the business from systematic over-notification and the reputational harm that follows.
This is a low-complexity backend service with a single declared dependency on the Notification Preferences Repository, making it straightforward to schedule and deliver. The main project risk is sequencing: this service must be available and stable before any notification dispatch pipeline is considered complete, since it gates all outbound notifications. Testing requirements include unit tests for the opt-in default behaviour, opt-out enforcement per scenario type, and the reset-all flow. Integration testing should validate the full loop from user preference update through to dispatch gating.
No localisation or content concerns apply here — this is pure business logic, so delivery should be predictable and low-risk.
This service layer wraps the `notification-preferences-repository` and exposes four methods: `getUserPreferences()`, `isScenarioEnabled()`, `setScenarioOptOut()`, and `resetAllPreferences()`. The critical contract is `isScenarioEnabled()`, which is called synchronously in the trigger engine's dispatch path — latency here directly affects notification throughput. The underlying repository uses upsert semantics with opted-in as the default when no record exists, so this service must not cache stale opt-out states between calls. Consider adding a short TTL in-memory cache for `isScenarioEnabled()` results if the trigger engine call volume warrants it, but invalidate on any `setScenarioOptOut()` write.
As a shared component, changes to the preference schema must be coordinated with all callers and the repository layer simultaneously.
Responsibilities
- Load all scenario preferences for a given user
- Update opt-in or opt-out state for a specific scenario type
- Expose a fast lookup used by the trigger engine to gate dispatch
Interfaces
getUserPreferences(userId)
isScenarioEnabled(userId, scenarioType)
setScenarioOptOut(userId, scenarioType, optedOut)
resetAllPreferences(userId)
Relationships
Dependencies (1)
Components this component depends on
Related Data Entities (2)
Data entities managed by this component