Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
89 changes: 89 additions & 0 deletions submissions/synapse-valkey_ziyad.md
Original file line number Diff line number Diff line change
@@ -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.