Challenge 2: Two Internal, Latency-Sensitive Microservices — Possible Solution
====================================================================

RECOMMEND: gRPC.

APPLYING THE FRAMEWORK
------------------------------
Q1 (Who's the client?): Both services are owned by YOUR OWN team —
this is exactly the "tightly coupled internal services you also
control" case the chapter said points toward gRPC. There's no
external, uncoordinated audience to accommodate, so gRPC's need for
generated client code from a shared .proto contract isn't a burden —
your team controls both ends and can regenerate that code whenever
the contract changes.

Q4 (What guarantees are needed?): The scenario explicitly calls out
"extremely low-latency" as a requirement. This is precisely gRPC's
strength over REST or GraphQL: Protocol Buffers' compact binary
encoding and HTTP/2 transport are measurably faster to serialize,
parse, and transmit than JSON over HTTP/1.1, which matters when
latency is a genuine, stated requirement rather than a nice-to-have.

WHY THIS WORKS AS AN ANSWER
------------------------------
Two conditions have to BOTH be true for gRPC to be the clear right
answer, and this scenario satisfies both simultaneously: (1) you
control both ends of the communication (so gRPC's tooling overhead
is a non-issue), and (2) there's a genuine, stated performance
requirement gRPC is specifically built to satisfy. If either
condition were missing — say, if this were a public-facing API
instead, or if latency genuinely didn't matter — REST would likely
be the simpler, equally valid choice instead.