📚 Class Notes – Notification System & Server–Client Communication

ఈ lectureలో ప్రధానంగా file-sharing systemలో server నుంచి multiple clientsకి file update notification ఎలా పంపాలి? అనే problemని solve చేస్తున్నాం.

Core requirement:

Serverలో file change జరిగినప్పుడు, interested clientsకి త్వరగా notification పంపాలి.

1. 🎯 Notification Service ఎందుకు అవసరం?

File synchronizationలో ఒక client fileని update చేస్తే:

Client A
   ↓
File changed
   ↓
Server updated
   ↓
Other Clients need to know
   ↓
Client B / C / D

Clientsకి:

“ఈ file update అయింది, synchronize చేసుకోండి”

అని notification ఇవ్వాలి.

ఇక్కడ notificationలో సాధారణంగా entire file ఉండదు.

Instead:

File ID
Version
Block hashes / metadata

లాంటివి పంపవచ్చు.

Client తర్వాత అవసరమైన blocksని server నుంచి download చేస్తుంది.

2. 🔑 Main Requirement

మన notification communicationకి requirements:

① Persistent connection

Client ప్రతి update కోసం కొత్త connection establish చేయకూడదు.

② Low latency

File change → notification చాలా త్వరగా వెళ్లాలి.

③ One-way communication

మన use caseలో:

Server → Client

చాలు.

④ Low overhead

Unnecessary requests ఉండకూడదు.

⑤ Scalable

Thousands/millions of clients ఉన్నా system handle చేయాలి.

3. Two Main Approaches

Server-client communicationలో రెండు fundamental approaches:

                 Communication
                      |
              ┌───────┴───────┐
              ↓               ↓
            Pull            Push

4. 🔄 Pull Model

Client periodically serverని అడుగుతుంది:

“ఏమైనా update ఉందా?”

Example:

Client → Server: Any update?
Server → Client: No

10 seconds later

Client → Server: Any update?
Server → Client: No

10 seconds later

Client → Server: Any update?
Server → Client: Yes!

ఇది Polling.

5. ❌ Polling Problems

Problem 1 — Delay

Suppose client ప్రతి 10 secondsకి poll చేస్తోంది.

Server update:

12:00:01 → File changed

Client next poll:

12:00:10

అంటే notificationకి 9 seconds delay.

File collaboration systemకి ఇది bad UX.

Problem 2 — Unnecessary Requests

File update లేకపోయినా:

Client → Server
Client → Server
Client → Server
Client → Server

requests వస్తూనే ఉంటాయి.

No update
   ↓
Still request
   ↓
Still request
   ↓
Still request

ఇది server resources waste చేస్తుంది.

6. 📌 Polling ఎందుకు మన use caseకి సరిపోదు?

File-sharing/collaboration systemలో:

Poll every 10 sec
→ latency too high

Poll every 1 sec
→ server load too high

అందువల్ల:

Frequent polling = expensive

Infrequent polling = slow

కాబట్టి Push model better.

7. 🚀 Push Model

Push modelలో client మొదట connection establish చేస్తుంది.

తర్వాత server దగ్గర update వచ్చినప్పుడు:

Client
   │
   │ Establish connection
   ↓
Server
   │
   │ connection remains open
   │
   │ File update happens
   ↓
Push notification
   ↓
Client

Client ప్రతి సారి అడగాల్సిన అవసరం లేదు.

8. Pushలో మూడు Important Technologies

ఈ lectureలో మూడు approaches చూశాం:

Push Communication
       |
 ┌─────┼──────────────┐
 ↓     ↓              ↓
Long   WebSocket      SSE
Polling

9. 🔄 Long Polling

Long polling అనేది normal pollingకి improved version.

Normal polling:

Client → Request
Server → Immediate response

Long polling:

Client → Request
           |
           | connection stays open
           |
           ↓
       Wait for update
           |
           ↓
Server → Response when update available

10. Long Polling Flow

Client
   |
   | HTTP Request
   ↓
Server
   |
   | Wait...
   |
   | File updated
   ↓
Response
   ↓
Client
   |
   | New long-poll request
   ↓
Server

అంటే update వచ్చేవరకు server responseని delay చేస్తుంది.

11. 👍 Long Polling Advantage

Normal pollingలో:

Update → next polling interval → response

Long pollingలో:

Update
  ↓
Immediate response

అందువల్ల latency తగ్గుతుంది.

Implementation కూడా relatively simple, ఎందుకంటే HTTPనే ఉపయోగించవచ్చు.

12. ❌ Long Polling Problems

Connection openగా ఉండేంత వరకు server resources consume అవుతాయి.

10,000 clients
      ↓
10,000 open requests
      ↓
Server resources occupied

Large scaleలో:

Resource consumption
Connection management complexity
Potential latency spikes
Reconnection handling

వంటి problems వస్తాయి.

అందువల్ల long polling workable అయినా, ideal solution కాదు.

13. 🔌 WebSocket

WebSocket కూడా initialగా HTTP requestతో ప్రారంభమవుతుంది.

Client
   |
   | HTTP handshake
   ↓
Server
   |
   | Successful upgrade
   ↓
WebSocket connection

Connection establish అయిన తర్వాత persistent TCP connection మీద data flow అవుతుంది.

14. WebSocket = Bidirectional

ఇది ముఖ్యమైన interview point.

Client  ←────────→  Server
          WebSocket

రెండు directionsలో communication చేయవచ్చు.

Example

Chat application:

Client → Server
"Hello"

Server → Client
"Hi"

15. WebSocket Use Cases

WebSocket చాలా useful:

Chat applications
Real-time games
Live collaboration
Trading applications
IoT
Real-time dashboards
Live tracking

ఎందుకంటే:

Low-latency + bidirectional communication

16. ❓ WebSocket మన File Sync systemకి ఎందుకు ideal కాదు?

మన requirement:

Server → Client

అంతే.

Client నుంచి persistent connectionలో data పంపాల్సిన అవసరం లేదు.

అందువల్ల WebSocket యొక్క bidirectional capability మనకు అవసరం లేని extra functionality.

Important:

WebSocket wrong technology అని కాదు.

కేవలం:

Our requirementకి SSE మరింత natural fit.

17. 📡 SSE — Server-Sent Events

SSE = Server-Sent Events

ఇది server → client real-time event streaming కోసం design చేయబడింది.

Basic flow:

Client
   |
   | HTTP request
   ↓
Server
   |
   | Keep connection open
   |
   | Event occurs
   ↓
Client

18. SSE = Unidirectional

ఇది అత్యంత ముఖ్యమైన point.

Server
   │
   │ Events
   ↓
Client

కానీ:

Client ───X───→ Server

అనే persistent communication ఉండదు.

అందుకే SSE:

Server → Client one-way real-time communication

కి suitable.

19. SSE Use Cases

Examples:

Notifications
News feeds
Social media updates
Stock price updates
Status updates
Live event streams
Server progress updates

మన file-sharing notification system కూడా ఇదే category.

20. ⭐ Why SSE fits File Synchronization

మన requirement:

File changes on Server
        ↓
Notify Clients

అంటే:

Server ─────────→ Client

Exactly SSE communication model.

Advantages:

Persistent connection
Real-time notification
One-way communication
HTTP based
Lower overhead than polling
Suitable for event-based updates

21. ⚠️ SSE Limitation

SSE unidirectional.

Serverకి client connection alive ఉందో తెలుసుకోవడానికి application-level mechanism అవసరం కావచ్చు.

ఉదాహరణ:

Client disconnects
      ↓
Server may need to detect it

SSEకి WebSocketలాగా native bidirectional heartbeat mechanism లేదు.

అవసరమైతే application-level heartbeat / reconnection mechanism implement చేయాలి.

22. 🆚 Polling vs Long Polling vs WebSocket vs SSE

Feature	Polling	Long Polling	WebSocket	SSE
Persistent connection	❌	Temporary	✅	✅
Server → Client	✅	✅	✅	✅
Client → Server	Request based	Request based	✅	❌
Real-time	❌	Good	Excellent	Excellent
Server overhead	High	Medium/High	Low	Low
Bidirectional	❌	❌	✅	❌
Good for notifications	❌	👍	👍	⭐
File-sync use case	❌	Possible	Overkill	⭐ Best fit

23. 🧠 Complete Notification Flow

మన File Synchronization architectureతో combine చేస్తే:

              SERVER
                 |
        File blocks updated
                 ↓
           Watch Service
                 ↓
       Notification Service
                 ↓
          SSE Connection
                 ↓
       ┌─────────┼─────────┐
       ↓         ↓         ↓
    Client A  Client B  Client C
       ↓         ↓         ↓
 Local Update Service
       ↓
Compare block hashes
       ↓
Request missing blocks
       ↓
Download changed blocks
       ↓
Update local file

24. 🔥 Important Design Insight

Notification service file data transfer service కాదు.

దాని job:

“Something changed” అని clientsకి inform చేయడం.

Actual data synchronization:

Notification
     ↓
Client knows file changed
     ↓
Compare hashes
     ↓
Request missing blocks
     ↓
Download blocks

అందువల్ల notification channelలో 1 GB file పంపాల్సిన అవసరం లేదు.

25. 🧩 File Sync + Notification Integration

మనం previous classలో నేర్చుకున్న రెండు flowsని connect చేస్తే:

Client → Server

User edits file
      ↓
Watch Service
      ↓
Server Update Service
      ↓
Hash blocks
      ↓
Compare
      ↓
Upload changed blocks
      ↓
Server updated

తర్వాత:

Server → Other Clients

Server updated
      ↓
Watch Service
      ↓
Notification Service
      ↓
SSE
      ↓
Other Clients
      ↓
Local Update Service
      ↓
Get missing blocks
      ↓
Update local file

🎯 Interview Answer — 30 Seconds

“For a file synchronization system, clients need to receive near-real-time notifications when a file changes on the server. Polling is inefficient because frequent polling creates unnecessary server load, while infrequent polling introduces latency. Long polling reduces latency but keeps server resources tied to open requests. WebSockets provide bidirectional real-time communication, but our use case only needs server-to-client communication. Therefore, Server-Sent Events (SSE) are a good fit because they provide a persistent, low-overhead, unidirectional server-to-client event stream.”

🧠 Easy Memory Trick

POLLING
Client keeps asking
"What changed?"
        ↓
❌ Wasteful

LONG POLLING
Client asks
"Tell me when something changes"
        ↓
👍 Better
        ↓
But connection/resource cost

WEBSOCKET
Client ←→ Server
        ↓
⭐ Real-time + bidirectional
        ↓
May be overkill

SSE
Server ───→ Client
        ↓
⭐ Real-time + unidirectional
        ↓
🎯 Perfect for notification use case

⭐ Interview Golden Rule

Requirement → Technology

Periodic updates
      → Polling

Near real-time, simple HTTP
      → Long Polling

Real-time + Bidirectional
      → WebSocket

Real-time + Server → Client
      → SSE

File Synchronization:
File Change → Watch Service → Notification Service → SSE → Local Update Service → Missing Blocks Download → Local File Update

Friday, 28 August 2026

NOTIFICATIONS - System