Challenge 3: Pub/Sub or Queue? — Possible Solution
====================================================================

(a) Broadcasting a live "user is typing" indicator in a chat app —
PUB/SUB. A typing indicator is only meaningful RIGHT NOW — if a
recipient's client wasn't connected at the exact moment the indicator
was sent, there's no value in delivering it late; by the time they'd
receive it, the person may have already stopped typing or sent their
message. Fire-and-forget is not just acceptable here, it's actually
the correct semantic — a "missed" typing indicator was never something
worth persisting in the first place.

(b) Processing a payment that must eventually succeed even if the
payment worker was briefly offline — A QUEUE (Chapter 7). This is
exactly the opposite requirement: the message (the payment job)
absolutely must not be lost just because no consumer happened to be
listening at the moment it was created. A queue persists the job until
some consumer actually picks it up and processes it, regardless of
whether that happens immediately or after a worker restarts a minute
later. Using pub/sub here would risk silently losing a real payment
job forever if the worker was down for even a moment when it was
published — an unacceptable failure mode for something this
consequential.

The underlying test: does a message have value ONLY if delivered
immediately (pub/sub fits), or must it eventually be handled no matter
when a consumer becomes available (a queue is required)?