Skip to main content

Notification Service 🔔

The Notification Service is responsible for delivering user-facing notifications in ShopVerse based on domain events emitted by other services.

It is a purely event-driven service and does not participate in synchronous business workflows.

🎯 Responsibilities​

The Notification Service handles:

  • Consuming domain events from Kafka
  • Creating user notifications
  • Persisting notifications
  • Fetching notifications for users and admins
  • Marking notifications as read

🧠 Why a Separate Notification Service?​

Notifications are:

  • Asynchronous by nature
  • Non-critical to core workflows
  • Triggered by multiple services

Separating them ensures:

  • No impact on core transactions
  • Failure isolation
  • Easy extensibility (email, SMS, push notifications)

🏗️ High-Level Architecture​

The Notification Service does not expose public mutation APIs.

📡 Event Consumption Flow​

📦 Events Consumed​

Event TypeSource ServicePurpose
USER_REGISTEREDAuth ServiceWelcome notification
USER_LOGINAuth ServiceLogin alert
ORDER_PLACEDOrder ServiceOrder confirmation
PAYMENT_SUCCESSPayment ServicePayment confirmation
PRODUCT_CREATEDProduct ServiceAdmin notification

🗄️ Data Model​

Notification Document​

  • id
  • eventType
  • userEmail
  • message
  • timestamp
  • read (boolean)

MongoDB is used for:

  • Flexible schema
  • Fast writes
  • Read-heavy workloads

🔐 Security Model​

  • APIs accessed through API Gateway

  • Identity provided via:

    • X-User-Email
    • X-User-Role

Authorization Rules:​

  • Users → fetch only their notifications
  • Admins → fetch all notifications

🌐 APIs​

User APIs​

MethodEndpointDescription
GET/api/notificationsGet user notifications
PUT/api/notifications/{id}/readMark as read

Admin APIs​

MethodEndpointRoleDescription
GET/api/notifications/allADMINGet all notifications

🛡️ Idempotency Strategy​

Kafka events may be delivered more than once.

To handle this:

  • Each event contains a unique identifier
  • Duplicate checks prevent multiple notifications
  • Consumer logic is idempotent

⚠️ Failure Scenarios​

❌ Kafka Consumer Down​

  • Kafka retains events
  • Consumer resumes from last offset

❌ MongoDB Down​

  • Events are retried
  • Failure logged for investigation

❌ Duplicate Events​

  • Safely ignored due to idempotency checks

⚙️ Key Components​

  • NotificationConsumer – Kafka listener
  • NotificationService – Core logic
  • NotificationRepository – MongoDB persistence
  • NotificationController – Fetch APIs
  • GatewayHeaderAuthenticationFilter – Security
  • GlobalExceptionHandler – Error handling

📈 Scalability Considerations​

  • Stateless consumer instances
  • Kafka consumer groups enable horizontal scaling
  • MongoDB handles high write throughput
  • Read APIs can be cached if needed

🧪 Testing Strategy​

  • Unit tests for message building
  • Kafka consumer tests
  • Idempotency tests
  • Security tests for role enforcement

📌 Summary​

The Notification Service provides:

  • Asynchronous, reliable notifications
  • Zero coupling with core workflows
  • Scalable Kafka-based consumption
  • Secure access to user data

It enhances user experience without impacting system stability.