Notification system design.

Click on image to see full size. Read the comments for description.


One comment “Notification system design.”

  1. admin Says:

    Are you ready to dive into the fascinating world of Notification System Design?

    Objective
    The primary goal is to design a notification service capable of sending product-to-user notifications
    seamlessly across multiple channels while overcoming common challenges. Here are the core requirements:
    —————————————–
    1. Send API: Establish an authenticated
    endpoint to trigger notifications from various backend and microservices.

    2. Supported Channels: Support
    notification delivery through diverse channels like Email, SMS, and Push
    notifications.

    3. User Preferences: Empower users to
    personalize their notification preferences for each channel and notification
    type.

    4. Respecting Service Limits: Ensure
    compliance with downstream service limits (e.g., email or SMS providers) to
    prevent throttling or suspension.

    5. Scalability: Enable horizontal scaling
    to accommodate potentially unlimited growth.
    ——————————————
    A Quick Overview

    Let’s walk through a high-level overview
    of how this notification system works:
    ——————————————
    1. Your application calls the `/send`
    endpoint with details such as the recipient’s userID.
    2. The `/send` endpoint authenticates the
    request using OAuth2′s Client Credentials Flow.

    3. It fetches the user’s notification
    preferences from the database to determine their subscriptions.

    4. User attributes, such as email
    addresses or phone numbers, are retrieved from the database.

    5. The endpoint constructs a message
    object containing user attributes and content for each channel, excluding
    disabled channels.

    6. This message is sent to a fanout
    service, which distributes it to specific job queues based on the target
    channels.

    7. Each channel has its job queue and
    processor. Processors pick up jobs and request the corresponding service (e.g.,
    transactional email or SMS) for notification delivery.
    ————————————————-

    Important Architecture Decisions

    Key architecture decisions to note:
    ——————————————————
    - The `/send` endpoint only requires the
    `userID`, ensuring services that send notifications have no knowledge of
    user-specific data.

    - Load balancing ensures scalability and
    availability of the `/send` endpoint.

    - OAuth2 Client Credential Flow secures
    the endpoint for server-to-server communication.

    - User preferences are stored in a highly
    scalable NoSQL or key-value pair database.

    - Fanout efficiently duplicates messages
    for different channels.

    - Job queues and processors handle
    message processing, allowing asynchronous, controlled, and reliable delivery.

    - Job processors make API calls to
    external services for notification delivery.
    ———————————————————
    Why Job Queues and Processors?

    Job queues and processors serve multiple vital purposes:
    ———————————————————
    A) External delivery services can be
    slow, and queues enable asynchronous processing.

    B) Queue mechanisms control job rates,
    preventing throttling.

    C) In case of external service outages,
    job queues provide error handling without code modifications.

Add comment

You need to register , for comment of article.