From ce1de948a09f63503f1f293d9f4fb53fd4df7b77 Mon Sep 17 00:00:00 2001 From: ziyxdxhmed Date: Sun, 21 Jun 2026 13:34:38 +0530 Subject: [PATCH] Add documentation for Notification System project Added project documentation for the Notification System, detailing the architecture, tech stack, features, and challenges faced during development. --- submissions/synapse-valkey_ziyad.md | 89 +++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 submissions/synapse-valkey_ziyad.md diff --git a/submissions/synapse-valkey_ziyad.md b/submissions/synapse-valkey_ziyad.md new file mode 100644 index 0000000..1a2ee70 --- /dev/null +++ b/submissions/synapse-valkey_ziyad.md @@ -0,0 +1,89 @@ +# Notification System — Real-time push notification infrastructure + +--- + +## Attendee/Team Details + +**Name:** Ziyad Ahmed +**GitHub Username:** [ziyxdxhmed] +**LinkedIn Profile:** [www.linkedin.com/in/ziyxdxhmed] +**GitHub Project Repository:** [https://github.com/ziyxdxhmed/synapse-valkey] + +--- + +## Problem Statement Selected + +Notification System — Real-time push notification infrastructure + + +## Project Description + +This project is a highly scalable, real-time push notification infrastructure. It is designed for modern web and mobile applications that require instant alerts without relying on inefficient client-side polling. By acting as a central hub, it solves the problem of delayed communication between a backend system and active end-users, ensuring that critical events—like system alerts, messages, or updates—are delivered to specific connected clients with zero perceived latency. + +--- + +## Approach + +The core of the architecture relies on the Publish/Subscribe (Pub/Sub) model to ensure horizontal scalability and immediate data delivery. + +Instead of connecting the frontend directly to a monolithic backend, I introduced Redis as a high-speed message broker. When a notification is triggered via a RESTful API endpoint, the payload is published to a Redis channel. A Node.js WebSocket server acts as the subscriber, listening to this channel. The server maintains an active memory map of connected users and their specific socket IDs. When a message arrives, it is instantly routed and emitted only to the targeted user's active WebSocket connection, which is then rendered on the React frontend using a toast notification library. This decoupled approach allows the system to handle thousands of concurrent connections efficiently. + +--- + +## Tech Stack and Tools Used + +**Frontend:** React (Vite), HTML, CSS, socket.io-client, react-toastify +**Backend:** Node.js, Express, Socket.io +**Database:** Redis (in-memory data structure store / Message Broker) +**AI Tools/API:** Cursor / AI Coding Agent +**Cloud/Deployment:** [Specify where you deployed, e.g., Vercel, Railway, or Localhost] +**Other Tools:** Docker (for local Redis container), Postman (for API testing) + +--- + +## Key Features + +1. **Real-Time Pub/Sub Routing:** Instantaneous message delivery using Redis as a high-performance message broker. +2. **Targeted Delivery:** Dynamic mapping of unique User IDs to active Socket connections to ensure private, user-specific notifications. +3. **Trigger API:** A dedicated REST endpoint that allows external microservices or background jobs to trigger push notifications programmatically. +4. **Live UI Integration:** Instant visual feedback on the frontend using responsive, sliding toast notifications. + +--- + +## What is Working? + +The core end-to-end pipeline is fully functional. The backend successfully connects to the Redis broker using Docker. The REST API successfully publishes payloads to the Redis channel, and the WebSocket server accurately routes those messages to the correct, actively connected React frontend, triggering the UI alert in real-time. + +--- + +## What is Still in Progress? + +* Implementing offline queuing (saving undelivered notifications to a persistent database like MongoDB/PostgreSQL when a user is disconnected). +* Building an Admin Dashboard to manually dispatch and monitor global or user-specific alerts. +* Multi-device synchronization (clearing an alert on one tab instantly clears it on another). + +--- + +--- + +## Challenges Faced + +One of the main challenges was managing the WebSocket connection state and ensuring the mapping between `userId` and `socket.id` remained accurate, especially when handling unexpected client disconnects or page refreshes. Additionally, setting up the Redis container and ensuring the Express server communicated flawlessly with the Pub/Sub channels required careful orchestration of async events. + +--- + +## Learnings + +I gained significant hands-on experience with the Pub/Sub architectural pattern and learned how to decouple microservices using a message broker. I also deepened my understanding of WebSocket event lifecycles, real-time client-server communication, and how to rapidly prototype robust backend infrastructure using AI developer tools. + +--- + +## Future Improvements + +Given more time, I would integrate persistent database storage to handle missed notifications, add support for "Topics/Channels" so users can subscribe to specific categories of alerts, and implement robust authentication (like JWTs) to secure the WebSocket handshake. + +--- + +## Final Note + +This infrastructure was built with scalability in mind from the very first hour. By implementing Redis early on, this prototype avoids the common bottleneck of single-server WebSocket limits and is architecturally prepared to be scaled across multiple server instances.