साध्या HTTP ऐवजी तुम्ही WebSockets, SSE, किंवा long-polling कधी वापराल?

Question

IT Interview Practice · Accepted Answer

साधे HTTP हे **request/response** आहे: client विचारतो, server उत्तर देतो, संपले. **real-time** features (chat, live dashboards, notifications, collaborative editing) साठी हे कमकुवत ठरते, जिथे *server* ला काहीतरी नवीन मिळताच data push करावी लागते. हे पर्याय HTTP च्या client-initiated model भोवती फिरण्याचे मार्ग आहेत, जटिलतेच्या एका पट्ट्यासह:

```text
Long-polling   client ──req──▶ server ...holds... ──resp──▶ then immediately re-asks
               (near-real-time over plain HTTP; one message per held request)

SSE            client ──req──▶ server ═══stream of events═══▶ (one-way, server→client)
               (HTTP-based, text, auto-reconnect; NO client→server on same channel)

WebSocket      client ──handshake──▶ server ══full-duplex, both directions══▶
               (persistent TCP; low overhead; binary or text; you build the rest)
```

**Long-polling** हा सर्वत्र चालणारा fallback आहे: client एक सामान्य request करतो जो server ला data मिळेपर्यंत उघडा ठेवतो, मग client लगेच पुन्हा request करतो. ते साध्या HTTP वर push चे अनुकरण करते पण प्रत्येक message मागे एक request cycle वाया घालवते आणि latency जोडते.

**SSE (Server-Sent Events)** हा एका एकल दीर्घकाळ टिकणाऱ्या HTTP response वरील हलका, प्रमाणित **एकदिशीय** stream (server → client) आहे. फक्त server push करत असताना तो आदर्श आहे — live feeds, notifications, progress, streaming LLM tokens. तो सोपा आहे, सामान्य HTTP/2 वर चालतो (विशेष infrastructure नाही), आणि auto-reconnect करतो. मर्यादा: तो एकदिशीय व फक्त-text आहे.

**WebSockets** एका एकल HTTP connection ला एका persistent, **full-duplex** TCP channel मध्ये upgrade करतात जिथे दोन्ही बाजू किमान per-message overhead सह कधीही पाठवतात. खऱ्या द्विदिशीय, कमी-latency संवादासाठी तो वापरा: chat, multiplayer games, collaborative editors, trading. किंमत operational आहे — ते एक stateful connection आहे ज्यासाठी proxies, load balancers व autoscalers configure करावे लागतात, आणि reconnection, heartbeats व backpressure तुम्ही स्वतः बांधावे लागतात.

**थंबचा नियम:** default म्हणून साधे HTTP वापरा; server→client streaming साठी **SSE** वापरा; तुम्हाला खरोखर द्विदिशीय real-time हवे असेल तेव्हाच **WebSockets** कडे जा; **long-polling** ला सार्वत्रिक fallback म्हणून ठेवा.

## हे का महत्त्वाचे आहे

real-time transport निवडणे ही एक क्लासिक senior design निवड आहे जिथे भाबडे उत्तर ("प्रत्येक गोष्टीसाठी फक्त WebSockets वापरा") सहसा चुकीचे असते. Interviewers ला पाहायचे असते की तुम्ही साधन *संवाद-नमुन्याशी* जुळवता — एकदिशीय विरुद्ध द्विदिशीय, latency गरजा, message प्रमाण — आणि stateful, दीर्घकाळ टिकणाऱ्या connections च्या **operational खर्चाचे** मूल्यमापन करता: sticky sessions, scaling, proxy timeouts, आणि reconnection logic. "server updates push करतो" हे SSE अनेकदा WebSockets पेक्षा सोप्या पद्धतीने पुरे करते, आणि long-polling एक भक्कम fallback राहतो हे ओळखणे भडक पर्यायाकडे झुकण्याऐवजी खरा production अनुभव दर्शवते.

हे का महत्त्वाचे आहे

संबंधित प्रश्न