Challenge 1: Identify the Right Technique — Possible Solution
====================================================================

(a) A live cryptocurrency price ticker
    -> SERVER-SENT EVENTS (SSE)

    The client never needs to send anything back over this channel — it
    only ever receives price updates from the server. SSE gives instant,
    server-pushed updates with automatic browser reconnection, without
    the added complexity (connection management, load balancer sticky
    sessions) that WebSockets would introduce for zero actual benefit
    here, since nothing flows client-to-server on this specific feed.

(b) A two-player tic-tac-toe game
    -> WEBSOCKETS

    Both players need to send moves back to the server (and to each
    other) in real time, over the same live connection — this is
    genuinely two-way traffic. SSE can't do this at all (it's
    server-to-client only), and polling/long-polling would introduce
    noticeable lag between a player's move and their opponent seeing it,
    which matters for a game that depends on quick back-and-forth turns.

(c) A "new version available, refresh?" banner
    -> POLLING (or, if truly minimal urgency is acceptable, nothing more
       complex than an occasional check)

    This is about as low-urgency as real-time gets — a delay of even a
    minute or two before the banner appears is completely acceptable, and
    the event (a new deployment) happens rarely. A simple periodic check
    (e.g. every 60 seconds, or even just checking once when the tab
    becomes visible again) is more than sufficient; reaching for SSE or
    WebSockets here would be meaningful added complexity solving a
    problem that barely exists.

WHY THIS WORKS AS A DECISION FRAMEWORK
-------------------------------------------
- Ask "does the client ever need to send something back over this SAME
  channel, in real time?" If yes, SSE is ruled out entirely and
  WebSockets become the real candidate.
- Ask "how urgent is this, really?" A price ticker needs sub-second
  freshness; a version-available banner does not — the acceptable
  latency directly informs whether polling is embarrassingly sufficient
  or genuinely too slow.
- The "least complex tool that satisfies the actual requirement" is the
  right answer far more often than the most impressive-sounding one —
  this is the central judgment call this chapter is teaching.