The Notification Problem: Creating a Universal System Architecture for Web3 dApps

Notifications are the digital backbone of user engagement for modern applications. They alert users to important updates, drive app re-engagement, and deliver time-sensitive informa- tion. Yet, for developers, creating reliable notification systems remains one of the most frustrat- ing technical challenges due to fragmented providers, inconsistent behaviors across platforms, and complex implementation requirements.

Especially when developing a native version of the web app. Porting the existing notification architecture becomes a double work. Also when the notifications require more reliability, the dev might want to switch between a different push service for the native app making the development process of notifications for the same web and native app complicated. This article provides a modular approach to build a notification system that supports both web and native platforms by allowing switching between various push notification providers in a single architecture that is tailored for web3 dApps.

The Critical Need for Notifications in Web3 :

Beyond traditional application needs, Web3 applications present unique notification requirements that are essential to user experience.

• Wallet Activity Monitoring

• NFT Activities

• DeFi Alerts

• Governance Participation

• Market Events

Users can’t always actively monitor their on-chain activity, making reliable push notifications for the users is a foundational component of any successful Web3 application. It’s not just about sending the market/news alerts, most apps need to monitor the user’s on-chain activity. The user based on-chain notifications are not simple, the application has to monitor the user’s wallet- address or token-address or similar and then notify the user based on the alert configuration. Performing this operation for multi-user requires a heavily optimized multi thread approach.

The Notification Landscape: Understanding the Challenge

Anyone who’s built a modern app knows the struggle, notifications seem simple in concept but quickly become a technical nightmare across platforms. In Web3, this complexity increases exponentially.

The problem isn’t just technical complexity, It’s the fragmentation of notification services that makes the stuff uniquely difficult:

• Each platform (iOS, Android, web) uses completely different notification systems

• Provider APIs change frequently, breaking existing implementations

• User permission models vary wildly between platforms

• Subscription management becomes increasingly complex at scale

• Delivery reliability fluctuates unpredictably

Most projects end up maintaining separate notification codebases for each platform that they build but display the similar set of notifications, which is neither efficient nor sustain- able. The few unified solutions that do exist often limit customization options or create vendor dependencies that become problematic over time.

Figure 1: The notification implementation maze: multiple providers, platforms, and failure points

The Universal Notification Architecture for Web3

For applications that require notification system that involves management of multi threads in-order to track the on-chain events of user. The idea is to split the notification handling logic from the core app (server) itself and maintain a worker for this.

The Blueprint

To make the explanation simple let’s take the example of a user configurable wallet tracking app and we want to build both web and native app for this.

1. Wallet Configuration and Preference Storage

   The process begins when a user specifies one or more wallet addresses they wish to track. These configurations are stored in a backend database along with a unique UserID. Each entry includes:

   • A list of wallet addresses

   • User preferences for how and where they wish to receive notifications (e.g., push notifica- tions, email, telegram etc...)

This configuration step acts as the foundation for the personalized wallet event monitoring system.

2. Worker Assignment and WebSocket Subscription

   Once the configuration is saved, the system assigns the wallet addresses to a Wallet Worker. A Wallet Worker is a long running light weight service responsible for listening to events using Helius WebSocket connections or similar.

3. On-Chain Event Detection and Parsing

   When an on-chain event occurs for any subscribed wallet, the Helius WebSocket stream delivers the event payload to the worker. The worker then:

   • Parses the incoming event to extract metadata.

   • Identifies the users subscribed to the socket by interaction with the DB to get subscribed users.

   • Constructs a structured AlertMessage containing all relevant data.

This message forms the payload that will eventually be pushed to the user.

4. Message Queue Publishing via RabbitMQ

   The structured alert is published to a message queue system RabbitMQ. This enables decoupling between the event detection and the delivery layer. RabbitMQ ensures:

   • Asynchronous processing and buffering of messages

   • Scalable fanout of messages.

Delivery guarantees through message acknowledgements and retries

The queue serves as a central pipeline for routing event alerts to the notification handlers and it can handle millions of messages (Required for our case).

5. Event Handling and Notification Dispatch via Lambda

   Each message published to the queue can trigger a lightweight AWS Lambda function (or any serverless function). This function:

   • Parses the alert message to determine the event type and user ID

   • Queries the user’s notification preferences

   • Routes the message to the correct delivery mechanism:

     – Push notifications (e.g., Firebase Cloud Messaging)

     – Third-party services (e.g., Telegram, Discord, Email)

This layer handles the final delivery of blockchain event alerts to the user in a way that matches their preferred experience.

$$\[ \begin{array}{ll} \textbf{Algorithm:} & \text{Real-Time Wallet Tracking and Notification Distribution} \\ \\ \textbf{Procedure:} & \texttt{TrackWalletEvents(UserID, WalletList)} \\ 1. & \text{Store } (UserID, WalletList) \text{ in Config Database} \\ 2. & \text{Assign WalletList to a WalletWorker} \\ 3. & \textbf{for all } \text{WalletAddress in WalletList do} \\ 4. & \quad \text{WalletWorker subscribes to WalletAddress via Helius WebSocket} \\ 5. & \textbf{end for} \\ \\ \textbf{Procedure:} & \texttt{OnWalletEvent(EventData)} \\ 6. & \text{Extract } (WalletAddress, EventType, TxDetails) \text{ from EventData} \\ 7. & \text{Look up UserID associated with WalletAddress} \\ 8. & \text{Create AlertMessage (UserID, EventData)} \\ 9. & \text{Publish AlertMessage to RabbitMQ queue} \\ \\ \textbf{Procedure:} & \texttt{HandleNotification(AlertMessage)} \\ 10. & \text{Triggered by RabbitMQ via Lambda} \\ 11. & \text{Parse AlertMessage} \\ 12. & \textbf{if } \text{User prefers push notification then} \\ 13. & \quad \text{Send via FCM or Push Service} \\ 14. & \textbf{else if } \text{User prefers WebSocket then} \\ 15. & \quad \text{Send to WebSocket Gateway} \\ 16. & \textbf{else if } \text{User prefers Email/Other then} \\ 17. & \quad \text{Send via corresponding Notification Channel} \\ 18. & \textbf{end if} \\ \end{array} \]$$

The Cross-Platform Magic

The explanations above cover only the part of building an efficient notification system that monitors custom on-chain activity based on user requests. But how do we ensure that the system is cross-platform compatible?

The solution lies in mapping each user’s devices (web or mobile), the push service used (e.g., FCM, Expo, or Web Push API), and corresponding device tokens to their user profile. These mappings can be stored as part of the user’s metadata. When an event is detected, the Wallet Worker add this metadata to the alert, allowing MQ to choose the appropriate delivery channel. By doing so, the system becomes capable of sending notifications to the correct devices across multiple platforms based on the user’s preferences and environment.

WhatsApp-Like Reliable Notifications

Regardless of the push notification provider used, achieving a consistently high notification delivery success rate remains a challenge. Users may occasionally miss on-chain alerts due to network instability, device constraints, or service-specific limitations. Additionally, most push services impose restrictions on data size, payload type, or rate of delivery.

To overcome these issues, we adopt an approach similar to the one used by WhatsApp. Instead of delivering the entire message content via the push service, we log the full alert message in a database, along with a read/unread status. When an event occurs, we only send a lightweight push notification containing a unique message ID.

On the client side, the application listens for these push events. Upon receiving a message ID, the client fetches the full content from the backend using this ID and renders the notification in a custom format. This approach enables flexible notifications display (including images, emojis, or gifs), improves reliability, and ensures that no critical alerts are lost even if push delivery fails temporarily.

Further Exploration

The system is not limited to building a notification pipeline for a single use case. It can be extended into a modular, plug-and-play framework that supports a wide variety of notifications across different contexts. A core enabler of this flexibility is the use of a Message Queue (MQ). By decoupling event generation from event processing, the MQ allows the system to scale horizontally and support multiple types of workers — each specialized for a different purpose. For example, one worker might monitor NFT transfers, another might track token swaps, while a third could ingest off-chain alerts from external protocols or APIs.

These workers can independently push structured messages into the queue, which are then routed to actions responsible for dispatching user notifications across platforms. This architec- ture not only enhances system modularity but also makes it possible to dynamically plug in new sources of alerts or notification logic without disrupting the core pipeline. The MQ-based design also opens the door to advanced features such as:

• Priority-based message handling (e.g., critical security alerts vs. general activity)

• Retry and failover logic using dead-letter queues

• Rate-limited or batched notifications

• 

In essence, this architecture lays the groundwork for a universal, protocol agnostic Web3 notification platform that can evolve with user needs and ecosystem complexity.

Final Thoughts

Web3 apps are evolving fast, and the need for real-time, reliable, and cross-platform notifications is no longer optional, it’s essential. Building them shouldn’t feel like reinventing the wheel every time.

By decoupling the detection, processing, and delivery of alerts through a message queue system, we’re not just solving a notification problem. We’re designing a future proof architec- ture that can scale and adapt to notifications pipelines provided by the ecosystem protocols. Whether it’s a DeFi transaction, NFT transfer, or a DAO vote reminder, the same pipeline can handle it all. Finally the real unlock: Notification system that are modular, universal, and built to last.

This isn’t just a notification system—this is a framework for on-chain awareness.