Challenge 2: Explain Full-Duplex With a Scenario — Possible Solution
====================================================================

SCENARIO: A group chat where one user is typing a long message while
another user's earlier message is still being delivered

With full-duplex WebSockets:
  - User A can be actively typing and send their message the instant they
    hit "send" — the connection can carry User A's outgoing message AT
    THE SAME TIME the server is still pushing User B's message down to
    User A's client. Neither direction has to wait for the other to
    finish.
  - A "user is typing..." indicator can be sent from User A to the server
    (and broadcast to other users) continuously, in real time, WHILE
    User A is also receiving other people's messages in the same window
    — genuinely simultaneous two-way traffic over one connection.

With a half-duplex (request/response) alternative, e.g. long polling:
  - User A's client has an outstanding "wait for new messages" request
    open with the server. To SEND their own message, User A's client has
    to make a SEPARATE, independent HTTP request — the "waiting for new
    messages" and "sending my message" are two different request/response
    cycles, not one continuous two-way flow.
  - There's no clean way to send a continuous "typing..." signal without
    either firing off a new HTTP request every keystroke (wasteful) or
    batching it awkwardly — because the connection is not meant to carry
    ad hoc bursts of outgoing data whenever the user wants, only to
    request/receive one thing at a time.

THE NOTICEABLY BETTER USER EXPERIENCE
--------------------------------------
The chat feels genuinely "live" in both directions — messages appear the
instant they're sent, and typing indicators update instantly, regardless
of what else is happening on the connection. With a half-duplex
alternative, there's an inherent seam between "the channel that's
receiving" and "the channel that's sending" that either adds visible
latency (waiting to send until a poll cycle allows it) or requires extra
requests just to keep the "sending" side responsive — overhead that a
true full-duplex WebSocket connection simply doesn't need, because both
directions already share the same always-open channel.