Notification System Basics

A notification system pushes messages to users: in-app, email, SMS, Push. Core pieces: event source, routing, channel adapters, delivery, status tracking. This article explains the architecture and main points with a reference table.

Overview

• Event source: Orders, comments, alerts produce events; passed async via MQ or event bus.
• Routing: Based on user preferences, channel capability, content type → choose in-app/email/SMS/Push.
• Channel adapters: Each channel has different APIs (SMTP, SMS operators, FCM/APNs); adapter layer provides a unified interface.
• Delivery: Sync call or queue to channel; support retry, rate limit, degradation.
• Status: Track read, delivered, failed; for debugging and analytics.

Example

Example 1: Flow

Plain textCopy
Event (e.g. order paid) → MQ
  → Consumer: user preferences, template, routing
  → Build content (in-app/email/SMS/Push)
  → Send to channels
  → Record status

Example 2: Key points

Point	Description
Async	Events to MQ; do not block main flow
Template	Pick by type and channel; variable substitution
Rate limit	SMS, Push have cost and frequency limits; limit by user and channel
Retry	Retry on channel failure; send to DLQ after max attempts

Example 3: User preferences

• User can set "in-app only", "disable email", etc.; check preferences when routing and filter channels.

Example 4: Idempotency

• Same event may be consumed multiple times; deduplicate by event_id or idempotent send.

Core Mechanism / Behavior

• Decoupling: Main flow emits event; notification service consumes and sends. Failures in notification do not affect main flow.
• Multi-channel: One event can go to multiple channels; routing and preferences decide.
• Delivery: Sync for simple cases; queue for high volume and retry.

Key Rules

• Decouple main flow from notifications; use MQ; avoid notification failure affecting main business.
• Rate limit and degrade by channel; when one channel fails, others continue; can fallback to in-app or defer.
• Idempotent: Same event may be duplicated; deduplicate by event_id or idempotent send.

What's Next

See MQ Basics, Idempotency, Rate Limiting. See Retry/DLQ for failure handling.