Why gRPC for internal services?

The main win internally is the contract. A .proto file defines messages and services; clients and servers are generated in every language, so a field rename is a compile error in the caller, not a runtime 500 at 2 a.m. Then encoding: protobuf is smaller and faster to parse than JSON — meaningful when a service handles tens of thousands of requests per second or passes large payloads. HTTP/2 gives multiplexed streams over one connection and native bidirectional streaming for things like log tailing or live updates between services. Deadlines and cancellation propagate across calls, which is a real reliability feature.

Costs: you cannot curl it without extra tools, payloads on the wire are not readable, browsers cannot speak native gRPC (no control over HTTP/2 frames), and gRPC-Web needs a proxy. Load balancing is subtler: one long-lived HTTP/2 connection carries many requests, so an L4 balancer pins all of them to one backend; you need L7 balancing or client-side balancing with service discovery. Everyone on the team needs the toolchain.

So: REST or JSON at the edge for browsers and third parties; gRPC internally when there are many services, several languages, high call volume or streaming. Two services in one language at 50 rps do not need it — JSON with a shared OpenAPI schema is fine.