Scenario Notification Repository
Component Detail
Description
Data access layer for persisting and querying scenario-based push notification records, including trigger history, delivery status, and cooldown timestamps. Backed by Supabase Postgres with row-level security to scope access per user.
scenario-notification-repository
Summaries
The Scenario Notification Repository is the system of record that makes the notification centre a trustworthy product surface. By reliably persisting every notification dispatched — including delivery status, read state, and trigger history — the business can offer users a complete, auditable log of their interactions with the platform. The cooldown timestamp mechanism stored here is also what prevents users from being over-notified, protecting the user relationship and preventing churn driven by notification fatigue. Built on Supabase Postgres with row-level security, the data layer enforces user data isolation, supporting both privacy best practices and regulatory compliance requirements.
This is a medium-complexity data component backed by Supabase Postgres, with row-level security as a notable configuration requirement that must be tested explicitly during QA. The seven interfaces span creation, querying, cooldown management, read-state updates, and deletion — each requiring its own test cases with edge conditions (empty history, concurrent reads, pagination boundary). A key scheduling dependency is that this repository must be available before both the trigger engine (cooldown reads/writes) and the notification centre UI (history queries) can be integrated end-to-end. Row-level security policy configuration should be treated as a separate deliverable with its own acceptance criteria to avoid it becoming an untracked blocker late in the sprint.
This data component wraps Supabase Postgres and exposes seven interfaces covering the full notification record lifecycle. The `getLastTriggered()` and `updateLastTriggered()` methods are on the hot path of the trigger engine and should be optimised with an index on `(userId, scenarioType)`. The `getNotificationsForUser()` method supports `limit` and `offset` for cursor-based pagination — callers should not request unbounded result sets. Row-level security (RLS) policies must be configured in Supabase so that the backend service role can read/write all rows while client-side calls are scoped to the authenticated user's own records.
The `createNotification()` method should store the scenario's context data as a JSONB column to support future deep-link reconstruction without schema migrations. Soft-delete via `deleteNotification()` should be evaluated against hard-delete depending on audit requirements.
Responsibilities
- Create and persist notification records with scenario type and context data
- Query notification history per user for display in the notification centre
- Read and write last-triggered timestamps to enforce cooldown periods
- Mark individual notifications as read
Interfaces
createNotification(notification)
getNotificationsForUser(userId, limit, offset)
getLastTriggered(userId, scenarioType)
updateLastTriggered(userId, scenarioType, timestamp)
markAsRead(notificationId)
deleteNotification(notificationId)
getUnreadCount(userId)
Relationships
Dependents (2)
Components that depend on this component
Related Data Entities (2)
Data entities managed by this component