வெற்று HTTP-க்குப் பதிலாக எப்போது WebSockets, SSE, அல்லது long-polling ஐப் பயன்படுத்துவீர்கள்?

Question

IT Interview Practice · Accepted Answer

வெற்று HTTP என்பது **request/response**: client கேட்கிறது, server பதிலளிக்கிறது, முடிந்தது. *Server* புதிதாக ஏதேனும் இருக்கும்போதெல்லாம் data ஐ push செய்ய வேண்டிய **real-time** features களுக்கு (chat, live dashboard கள், notification கள், collaborative editing) இது மோசமான பொருத்தம். HTTP-இன் client-தொடங்கிய 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 சுழற்சியை வீணடித்து latency ஐச் சேர்க்கிறது.

**SSE (Server-Sent Events)** என்பது ஒரு லேசான, தரப்படுத்தப்பட்ட **one-way** stream (server → client) ஒரு ஒற்றை நீண்டகால HTTP response-இன் மேல். server மட்டும் push செய்யும்போது இது ideal — live feed கள், notification கள், progress, streaming LLM token கள். இது எளிமையானது, சாதாரண HTTP/2-இன் மேல் இயங்குகிறது (சிறப்பு infrastructure இல்லை), மற்றும் auto-reconnect செய்கிறது. வரம்பு: இது one-directional மற்றும் text-only.

**WebSockets** ஒரு ஒற்றை HTTP connection ஐ ஒரு நிரந்தர, **full-duplex** TCP channel ஆக upgrade செய்கிறது, அங்கு இரு பக்கங்களும் குறைந்தபட்ச per-message overhead உடன் எந்நேரமும் அனுப்புகின்றன. உண்மையாக bidirectional, குறைந்த-latency interaction-க்கு இதைப் பயன்படுத்துங்கள்: chat, multiplayer game கள், collaborative editor கள், trading. இதன் விலை operational — இது ஒரு stateful connection, proxy கள், load balancer கள், மற்றும் autoscaler கள் இதற்குக் configure செய்யப்பட வேண்டும், மேலும் reconnection, heartbeat கள், மற்றும் backpressure ஐ நீங்களே கட்டமைக்க வேண்டும்.

**கட்டைவிரல் விதி:** வெற்று HTTP ஐ default ஆக வையுங்கள்; server→client streaming-க்கு **SSE** ஐப் பயன்படுத்துங்கள்; உண்மையாக bidirectional real-time தேவைப்படும்போது மட்டுமே **WebSockets**-ஐ எட்டுங்கள்; **long-polling** ஐ உலகளாவிய fallback ஆக வையுங்கள்.

## இது ஏன் முக்கியம்

ஒரு real-time transport ஐத் தேர்ந்தெடுப்பது ஒரு classic senior design முடிவு, அங்கு அப்பாவித்தனமான பதில் ("எல்லாவற்றுக்கும் WebSockets ஐப் பயன்படுத்து") பொதுவாக தவறு. நீங்கள் கருவியை *communication pattern*-க்கு பொருத்துகிறீர்களா என்பதை interviewer கள் பார்க்க விரும்புகிறார்கள் — one-way vs bidirectional, latency தேவைகள், message அளவு — மேலும் stateful, நீண்டகால connection களின் **operational cost** ஐ நீங்கள் எடைபோடுகிறீர்களா: sticky session கள், scaling, proxy timeout கள், மற்றும் reconnection logic. SSE பெரும்பாலும் "server update களை push செய்கிறது" ஐ WebSockets ஐ விட எளிமையாக மூடுகிறது என்பதையும், long-polling ஒரு உறுதியான fallback ஆக நிலைத்திருக்கிறது என்பதையும் அங்கீகரிப்பது, மிகவும் ஜோடனையான option ஐ எட்டுவதற்குப் பதிலாக நிஜமான production அனுபவத்தைக் காட்டுகிறது.

இது ஏன் முக்கியம்

தொடர்புடைய கேள்விகள்