Challenge 2: Server or Client Interceptor? — Possible Solution
====================================================================

(a) Logging how long every call took to complete — EITHER could work,
but SERVER is typically the more natural place for the authoritative
measurement, since the server sees the actual processing time for its
own handler; a client interceptor could ALSO measure round-trip time
from its own perspective (useful for a different purpose — measuring
what the caller actually experienced, including network latency). In
practice, teams often log on both sides for different reasons, but if
only one, server-side handler duration is the more common default.

(b) Rejecting calls that exceed a rate limit — SERVER. Rate limiting
protects the SERVER from being overwhelmed by too many calls — this
only makes sense enforced on the receiving side, which is the only
side that actually knows the current aggregate call volume across
potentially many different clients. A client has no way to enforce a
limit that's fundamentally about protecting someone else's resource.

(c) Automatically retrying a failed call up to 3 times — CLIENT. Retry
logic belongs to whoever is INITIATING the call and deciding whether
it's worth trying again — the client is the one waiting for a result
and the one that can decide to resend the exact same request. A server
has no concept of "retrying" an incoming call it already received and
processed once.