ਤੁਸੀਂ ਸਾਦੇ HTTP ਦੀ ਬਜਾਏ WebSockets, SSE, ਜਾਂ long-polling ਕਦੋਂ ਵਰਤੋਗੇ?

Question

IT Interview Practice · Accepted Answer

ਸਾਦਾ HTTP **request/response** ਹੈ: client ਪੁੱਛਦਾ ਹੈ, server ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਖ਼ਤਮ। ਇਹ **real-time** features (chat, ਲਾਈਵ dashboards, notifications, collaborative editing) ਲਈ ਮਾੜਾ fit ਹੈ ਜਿੱਥੇ *server* ਨੂੰ ਜਦੋਂ ਵੀ ਕੁਝ ਨਵਾਂ ਹੋਵੇ data push ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਵਿਕਲਪ HTTP ਦੇ client-ਸ਼ੁਰੂ ਕੀਤੇ ਮਾਡਲ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਰਾਹ ਲੱਭਣ ਦੇ ਤਰੀਕੇ ਹਨ, ਗੁੰਝਲਦਾਰੀ ਦੇ ਇੱਕ ਵਰਣਪਟ ਦੇ ਨਾਲ:

```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 ਦੇ ਨੇੜੇ ਪਹੁੰਚਦਾ ਹੈ ਪਰ ਹਰ ਸੁਨੇਹੇ ਲਈ ਇੱਕ request cycle ਬਰਬਾਦ ਕਰਦਾ ਹੈ ਅਤੇ latency ਜੋੜਦਾ ਹੈ।

**SSE (Server-Sent Events)** ਇੱਕ ਇਕੱਲੇ ਲੰਬੇ HTTP response 'ਤੇ ਇੱਕ ਹਲਕਾ, ਮਿਆਰੀ **ਇੱਕ-ਪਾਸੜ** stream (server → client) ਹੈ। ਇਹ ਉਦੋਂ ਆਦਰਸ਼ ਹੈ ਜਦੋਂ ਸਿਰਫ਼ server push ਕਰਦਾ ਹੈ — ਲਾਈਵ feeds, notifications, progress, streaming LLM tokens। ਇਹ ਸਾਦਾ ਹੈ, ਆਮ HTTP/2 'ਤੇ ਚੱਲਦਾ ਹੈ (ਕੋਈ ਖ਼ਾਸ infrastructure ਨਹੀਂ), ਅਤੇ ਆਪਣੇ-ਆਪ reconnect ਕਰਦਾ ਹੈ। ਸੀਮਾ: ਇਹ ਇੱਕ-ਪਾਸੜ ਅਤੇ ਸਿਰਫ਼-text ਹੈ।

**WebSockets** ਇੱਕ ਇਕੱਲੇ HTTP connection ਨੂੰ ਇੱਕ ਸਥਾਈ, **full-duplex** TCP channel ਵਿੱਚ upgrade ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਦੋਵੇਂ ਪਾਸੇ ਘੱਟੋ-ਘੱਟ per-message overhead ਨਾਲ ਕਿਸੇ ਵੀ ਵੇਲੇ ਭੇਜਦੇ ਹਨ। ਇਸਨੂੰ ਸੱਚਮੁੱਚ ਦੋ-ਪਾਸੜ, low-latency ਪਰਸਪਰ ਕਿਰਿਆ ਲਈ ਵਰਤੋ: chat, multiplayer games, collaborative editor, trading। ਕੀਮਤ ਪਰਿਚਾਲਨ ਵਾਲੀ ਹੈ — ਇਹ ਇੱਕ stateful connection ਹੈ ਜਿਸ ਲਈ proxy, load balancer, ਅਤੇ autoscaler ਨੂੰ configure ਕਰਨਾ ਪੈਂਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ reconnection, heartbeat, ਅਤੇ backpressure ਖ਼ੁਦ ਬਣਾਉਣੇ ਪੈਂਦੇ ਹਨ।

**ਅੰਗੂਠੇ ਦਾ ਨਿਯਮ:** ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਾਦਾ HTTP ਵਰਤੋ; server→client streaming ਲਈ **SSE** ਵਰਤੋ; **WebSockets** ਤੱਕ ਸਿਰਫ਼ ਉਦੋਂ ਪਹੁੰਚੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਦੋ-ਪਾਸੜ real-time ਦੀ ਲੋੜ ਹੋਵੇ; **long-polling** ਨੂੰ ਸਰਵਵਿਆਪਕ fallback ਵਜੋਂ ਰੱਖੋ।

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਇੱਕ real-time transport ਚੁਣਨਾ ਇੱਕ ਕਲਾਸਿਕ senior ਡਿਜ਼ਾਈਨ ਫ਼ੈਸਲਾ ਹੈ ਜਿੱਥੇ ਭੋਲਾ ਜਵਾਬ ("ਹਰ ਚੀਜ਼ ਲਈ ਬਸ WebSockets ਵਰਤੋ") ਆਮ ਤੌਰ 'ਤੇ ਗ਼ਲਤ ਹੁੰਦਾ ਹੈ। Interviewers ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਸੰਦ ਨੂੰ *ਸੰਚਾਰ pattern* ਨਾਲ ਮੇਲਾਉਂਦੇ ਹੋ — ਇੱਕ-ਪਾਸੜ ਬਨਾਮ ਦੋ-ਪਾਸੜ, latency ਦੀਆਂ ਲੋੜਾਂ, ਸੁਨੇਹੇ ਦੀ ਮਾਤਰਾ — ਅਤੇ ਕਿ ਤੁਸੀਂ stateful, ਲੰਬੇ ਸਮੇਂ ਵਾਲੇ connection ਦੀ **ਪਰਿਚਾਲਨ ਲਾਗਤ** ਨੂੰ ਤੋਲਦੇ ਹੋ: sticky sessions, scaling, proxy timeout, ਅਤੇ reconnection logic। ਇਹ ਪਛਾਣਨਾ ਕਿ SSE ਅਕਸਰ "server updates push ਕਰਦਾ ਹੈ" ਨੂੰ WebSockets ਨਾਲੋਂ ਸਾਦੇ ਢੰਗ ਨਾਲ ਢੱਕ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਕਿ long-polling ਇੱਕ ਮਜ਼ਬੂਤ fallback ਰਹਿੰਦਾ ਹੈ, ਇਹ ਸਭ ਤੋਂ ਭੜਕੀਲੇ ਵਿਕਲਪ ਵੱਲ ਹੱਥ ਵਧਾਉਣ ਦੀ ਬਜਾਏ ਅਸਲ production ਤਜਰਬੇ ਦਾ ਸੰਕੇਤ ਦਿੰਦਾ ਹੈ।

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ