Decision Matrix

Latency 만족하는 가장 가벼운 도구를 골라

네 가지 real-time 접근 방식은 서열 아니야. 결정 matrix 야. 옳은 답은 세 질문에 달려있어: 방향 (일방향 vs 양방향?), 빈도 (분당 한 번 vs 초당 열 번?), 허용 latency (30초 지연 ok 인지, 100ms 미만 필요한지?).

Flowchart

분당 한 번 fresh data 면 polling 으로 충분. 서버만 push 하면 SSE 가 가장 가벼운 옳은 답. 양쪽 다 자주 push 하고 latency 가 빡세면 WebSocket. 양쪽 다 push 안 많이 하고 데이터가 request-response 모양 맞으면 real-time 자체를 쓰지 마.

Hybrid 가 normal

대부분의 production 시스템이 모양 섞어 써. cwkPippa: REST 로 conversation CRUD, SSE 로 AI 토큰 stream, polling 으로 fleet heartbeat. ChatGPT: HTTP POST 로 user input, SSE 로 reply stream. Slack: WebSocket 으로 chat + SSE 로 일부 notification + REST 로 모든 CRUD. real-time 은 도구 하나가 아니야.

Code

Decision flowchart·text

  Do you need real-time updates at all?
  |-- No  -> Use plain HTTP/REST.
  |-- Yes
      |-- Server -> Client only?
      |   |-- Yes -> SSE (Server-Sent Events).
      |   |-- No (bidirectional)
      |       |-- Frequency low + latency tolerant -> long polling can suffice.
      |       |-- Frequency high or latency tight  -> WebSocket.
      |-- Need binary frames?
          |-- Yes -> WebSocket (SSE is text-only).

한눈에 보는 matrix·text

| Approach     | Direction        | Latency      | Complexity | Best for                           |
| ------------ | ---------------- | ------------ | ---------- | ---------------------------------- |
| Polling      | client-driven    | interval     | very low   | dashboards refreshing every 30s+   |
| Long Polling | server -> client | low-medium   | medium     | legacy, when SSE/WS blocked        |
| SSE          | server -> client | low          | low        | AI streaming, notifications, feeds |
| WebSocket    | bidirectional    | very low     | higher     | chat, collab, gaming, trading      |

Exercise

다음 각 기능에 대해 옳은 접근 (polling / long-polling / SSE / WebSocket) 적고 *왜* 인지 한 줄 적어: (a) GitHub Actions 빌드 상태 badge, (b) Figma 의 live cursor, (c) 안 읽은 메일 notification badge count, (d) Discord chat, (e) ChatGPT 응답 streaming, (f) public homepage 의 live stock ticker. 각각 방어 가능한 답 하나씩 있어.