Building a Scalable Notification Service with gRPC and Microservices

Notification Services have become ubiquitous, serving as a cornerstone for timely updates and alerts to users. This article focuses on the technical nuances inherent in architecting a Notification Service, considering it a comprehensive concept encompassing various essential components.

Check out this video first to understand how will this notification infrastructure platform work?

Diverse Use Cases

The architectural considerations of notification infrastructure discussed here are designed to cater to diverse use cases, specifically emphasizing scenarios such as price changes and item availability. The flexibility of the proposed architecture allows seamless customization to meet specific product requirements. Users also seek out multi-tenancy in their notification infrastructure.

Price Change

In the realm of e-commerce notification services, users often seek notifications regarding price drops for products of interest. The outlined architecture proves to be adaptable, accommodating different product requirements seamlessly.

Item Availability

Similar flexibility extends to notifying users about the availability of previously out-of-stock items. Leveraging the same underlying logic used for price changes, the architecture is versatile for various use cases.

Explicit Requirements

Product Requirements

1. User Interaction: Authenticated users should be able to create notifications to "watch" or follow a product for price change alerts. This functionality is typically accessible from a product page linked from search results.

2. Notification Delivery: The service should reliably dispatch email or push notifications to users upon detecting a price change for a watched product.

3. Notification List: Users should receive a comprehensive list of product notifications via email. For push notifications, rules should determine which product to prioritize, especially when users monitor multiple products.

4. Third-Party Integration: The service must seamlessly function with products that incorporate price comparisons from diverse third-party sources.

Design Goals

1. Integration: The notification service should effortlessly integrate with existing services such as e-commerce or job search products.

2. Isolation: The notification service should maintain a high degree of isolation, constituting its own components independent of the main service.

Central Component: Notification API

At the core of the Notification Service architecture lies the Notification API, a critical component enabling the creation and deletion of notification entries via an API. This API is invoked by the existing service to manage notifications effectively.

Notification API High-Level Design

Key features of the Notification API encompass:

• Create Notification: Initiates the creation of a new notification entry with parameters including API key, product ID, and user ID.

• Delete Notification: Removes an existing notification based on the API key and notification ID.

• Get Notifications: Retrieves a list of notifications for a specific user.

Database Schema

The Notification API relies on a database with the following schema:

• NotificationID: A unique identifier for each notification entry.

• UserID: The ID of the logged-in user who created the notification.

Additional fields in the schema (e.g., ProductID, LatestPrice, PreviousPrice, LastUpdated) vary depending on the product or service. In this example, an e-commerce website is considered.

Technical Implementation

The Notification API can be implemented as a RESTful or gRPC service using languages like Java, Go, or C#. The choice of a NoSQL datastore and a caching system depends on specific requirements.

Optional: User Data Component

To maintain a clear separation of responsibilities, the Notification API ideally only stores user references. Personally Identifiable Information (PII) data, such as names and emails, should be stored in a separate API.

Diverse Approaches

Several solutions can be employed, each with its own pros and cons. The following design solutions can be combined for optimal results.

Solution #1: Manual Price Update Event

Suitability:

This solution is tailored for scenarios where internal control over product prices is absolute.

Pros:

1. Simplicity of Implementation:

   • The straightforward integration makes it an ideal choice.
   • Minimal development effort compared to other solutions.

2. Full Control:

   • Precise management of price changes internally.
   • Offers reliability and accuracy.

Cons:

1. Limited Applicability:
   • Unsuitable when relying on third-party sources for price changes.
   • Restricts flexibility in the face of external pricing influences.

Components:

1. Communication Service:

   • Manages notification flow to end-users.

2. Price Change Event:

   • Triggered manually via the admin panel.

3. Notification Service:

   • Handles and manages notifications.

High-Level Design (RDBMS Database):

-- SQL Query for RDBMS

SELECT * FROM NOTIFICATIONS WHERE PRODUCT_ID = 'xxx' AND ANOTHER_COL = 'xxx';

High-Level Design (NoSQL Database with Indexing Service):

{

  'xxx-xxx-xxx': {'notifications': ['xxx-xxx-xxx', 'xxx-xxx-xxx', 'xxx-xxx-xxx']}

}

Indexing Service

• RDBMS: Not required, as the Notifications API can execute an SQL query directly.
• NoSQL: Necessary for mapping product IDs to notification IDs.

Rebuilding the Index:

• In case of failure, the index should be rebuilt.
• A backup service ensures continuous availability.
• Periodic updates maintain data accuracy.

Implementation Tip:

The indexing service can be a RESTful service or an in-memory data store like Redis.

Price Change Event Service

1. Monitoring: Monitors product price change events triggered by the admin panel.
2. Updates: Updates affected product prices via the Notification API.

Implementation Tip:

AWS Lambda or a similar service for event monitoring.

Communication Service

1. Abstraction: Serves as an abstraction between systems and third-party services.
2. Notification Delivery: Sends emails and push notifications.

Solution #2: Use Batch Jobs

Suitability:

This approach is suitable when relying on third-party sources for pricing.

Pros:

1. Comprehensive Coverage:
   • Ensures broad coverage by handling all stored criteria.

Cons:

1. Increased API Calls:

   • Potential drawback due to heightened internal API usage.

2. Database Scans:

   • Requires partial or full database scans.

3. Additional Components:

   • Introduces more running components.

Components:

1. Scheduler:

   • Triggers batch jobs.

2. Data Pipeline:

   • Gathers and publishes notifications to a queue.

3. Batch Jobs:

   • Process notifications from the queue.

4. Communication Service:

   • Manages notifications.

High-Level Design:

Scheduler

1. Scheduling: Triggers data pipeline, batch processing, and other services periodically.
2. Considerations: Off-peak times and user time zone for optimal notification delivery.

Scheduling Strategies:

1. Daily Coverage: Ensures all notifications are covered per day.
2. Regional Alternation: Alternates between regions or availability zones per day.

Implementation Tip:

Utilize a Cron Job or AWS Cloudwatch Event.

Data Pipeline

1. Triggering: Initiated by the scheduler.
2. Functionality: Scans the database, groups notifications, and publishes them to a queue.
3. Reading Strategy: Consider full database scan or partial scan grouped by regions.

Implementation Tip:

Use AWS Data Pipeline, Spark, or similar services for efficient data processing.

Batch Jobs

1. Subscription: Subscribed to the notification entries topic in the message queue.
2. Processing: Picks up messages, calls internal APIs, compares prices, and decides whether to notify users.
3. Updates: Updates notification entries in the database after successful communication.

Implementation Tip:

Leverage AWS Data Pipeline, Spark, or similar services for efficient message processing.

Solution #3: Use Internal API Response Logs

Suitability:

Efficient for scaling up services and reducing internal API calls.

Pros:

1. Real-time Updates:
   • Provides more "real-time" price updates.
2. Reduced API Calls:
   • Mitigates the number of internal API calls.

Cons:

1. Log Streaming Requirement:
   • Mandates log streaming for optimal functionality.
2. Frequency Logic Tuning:
   • Requires fine-tuning of frequency logic for notifications.

Components:

1. Scheduler:

   • Triggers Samza job.

2. Data Pipeline:

   • Processes API request and response logs.

3. Samza Job:

   • Matches live user requests with notifications.

4. Communication Service:

   • Manages notifications.

High-Level Design (RDBMS Database):

-- SQL Query for RDBMS

SELECT * FROM NOTIFICATIONS WHERE SEARCH_CRITERIA = 'xxx';

High-Level Design (NoSQL Database with Indexing Service):

{

  'xxx-xxx-xxx': {'notifications': ['xxx-xxx-xxx', 'xxx-xxx-xxx', 'xxx-xxx-xxx']}

}

API Response Logs

1. Logging: Logs both request and response when a user views a product.
2. Inclusion: Product and price details are included in the logs.

Implementation Tip:

Utilize Kafka for log streaming and Samza for processing.

Samza Job

1. Matching: Matches live user requests with notifications.
2. Evaluation: Checks for price differences or product availability.
3. Notification: Sends a request to the communication component for user notification.

Implementation Tip:

Leverage Kafka for log stream and Samza for data processing.

Critical Considerations:

1. Avoiding Duplicates:

   • Skip notifications updated within a specified period to prevent duplicates.

2. Fine-tuning Frequency:

   • Adjust the frequency of sending notifications to avoid overwhelming users.

Combining All Solutions

These solutions have their own strengths and weaknesses. Implementing all of them side by side can deliver the best results. A recommended approach is to start with Solution #1, then expand to Solution #2 as the product scales. Finally, when the notifications database faces excessive load, consider implementing Solution #3.

Technical Notes

• Services Communication:

  • Achieved via HTTPS calls for secure and reliable communication.

• Redundancy Considerations:

  • Add a load balancer for redundancy.
  • Deploy services in multiple regions for enhanced availability.

In conclusion, architecting a scalable notification service requires thoughtful consideration of use cases, requirements, and the strengths of different solutions. By combining various approaches, developers can create a robust notification infrastructure that effectively informs and engages users.

How SuprSend Notification Infrastructure Can Power Your Complete Stack?

We can help you abstract your developmental layer without compromising quality and code. Our team is led by two experienced co-founders who have a combined experience of more than 20 years in building notification stacks for different early/mid-to-large-sized companies. We've been through the ups and downs, the sleepless nights, and the moments of triumph that come with creating a dependable notification infrastructure.

This is our amazing team, and we're here to make your journey unforgettable :)

Now let's see how SuprSend can benefit you:

1. Multi-Channel Support:

   • Add multiple communication channels (Email, SMS, Push, WhatsApp, Chat, App Inbox) with ease.
   • Seamless integration with various providers.
   • Flexible channel routing and management.

2. Visual Template Editors:

   • Powerful, user-friendly template editors for all channels.
   • Centralized template management.
   • Versioning support for templates, enabling rapid changes without code modification.

3. Intelligent Workflows:

   • Efficient notification delivery through single triggers.
   • Configurable fallbacks, retries, and smart routing between channels.
   • Handle various notification types (Transactional, Crons, Delays, Broadcast) effortlessly.

4. Enhanced User Experience:

   • Preference management for user control.
   • Multi-lingual content delivery.
   • Smart channel routing and batching to avoid message bombardment.
   • Frequency caps and duplicate prevention.

5. Comprehensive Analytics and Logs:

   • Real-time monitoring and logs for all channels.
   • Cross-channel analytics for message performance evaluation.
   • Receive real-time alerts for proactive troubleshooting.

6. Developer-Friendly:

   • Simplified API for triggering notifications on all channels.
   • SDKs available in major programming languages.
   • Comprehensive documentation for ease of integration.

7. App Inbox:

   • Customizable inapp-inbox for your app and website.
   • Provides a convenient way to centralize and manage notifications for users.
   • Try our app-inbox playground here: SuprSend_AppInbox_Playground

8. Bifrost Integration:

   • Run notifications natively on a data warehouse for enhanced data management.

9. User-Centric Preferences:

   • Allow users to set their notification preferences and opt-out if desired.

10. Scalable and Time-Saving:

    • Quickly deploy notifications within hours, saving development time.
    • Minimal effort is required to set up notifications. Get started in under 5 minutes.

11. 24*7 Customer Support:

    • Our team is distributed around various time zones, ensuring someone is always up to cater to customer queries.
    • We also received the 'Best Customer Support' badge from G2 for our unwavering dedication.

Still not convinced?

Let's talk, and we may be able to give you some super cool notification insights. And no commitments, we promise!

You can find Gaurav, CTO & cofounder, SuprSend here: GV

You can find Nikita, cofounder, SuprSend here: Nikita

To directly book a demo, go here: Book Demo

Similar to this, I run a developer-centric community on Slack. Where we discuss these kinds of topics, implementations, integrations, some truth bombs, lunatic chats, virtual meets, and everything that will help a developer remain sane ;) Afterall, too much knowledge can be dangerous too.

I'm inviting you to join our free community, take part in discussions, and share your freaking experience & expertise. You can fill out this form, and a Slack invite will ring your email in a few days. We have amazing folks from some of the great companies (Atlassian, Gong, Scaler etc), and you wouldn't wanna miss interacting with them. Invite Form