Challenge 2: Explain Why Unary Doesn't Fit — Possible Solution
====================================================================

EFFICIENCY: polling with repeated unary calls means the client has to
establish and pay the overhead of a NEW request/response cycle every
single time it wants to check for an update — even during long
stretches where the price hasn't changed at all, the client is still
sending requests and the server is still processing and responding to
each one, all for a "nothing changed" answer most of the time. Server
streaming instead keeps ONE connection open and only sends a new
message when the server actually HAS something new to say — no wasted
round trips checking for updates that aren't there.

DESIGN: polling forces the CLIENT to decide how often to check (poll
every second? every 5 seconds?) — too frequent wastes resources on
both ends for no benefit, too infrequent means updates arrive late.
Server streaming inverts this responsibility correctly: the SERVER,
which actually knows when a real price change happened, decides when
to push a new message — updates arrive exactly when they're genuinely
available, not on an arbitrary client-guessed schedule. This also
better reflects the real relationship being modeled: "notify me when
something changes" is fundamentally a server-driven, ongoing
relationship, not a sequence of independent question-answer
exchanges, which is what unary polling awkwardly forces it to become.