An organisation standardises internal service communication. What actually distinguishes gRPC from JSON over HTTP at scale, and where does each break down?

What genuinely differs

• Schema-first contracts with generated clients. The interface definition is the source of truth and clients are generated, so a breaking change is caught at build time rather than at runtime in production. This is the largest practical difference and it is about process more than protocol.
• Binary encoding with field numbers, which is smaller and faster to parse than JSON, and — more importantly — makes field addition and removal well-defined: unknown fields are ignored, removed fields leave their numbers reserved, and compatibility rules are mechanical rather than conventional.
• HTTP/2 multiplexing. Many concurrent calls on one connection with no head-of-line blocking at the HTTP layer, which matters a great deal for chatty internal traffic.
• First-class streaming in both directions, which over HTTP/1.1 JSON requires long-polling, chunked responses or websockets.
• Deadlines as a protocol feature, propagated automatically — a substantial reliability benefit that is easily overlooked and is arguably the best reason to adopt it.

Where gRPC breaks down

• Browser clients need a proxy layer, since browsers cannot speak raw gRPC. This is solvable and is friction.
• Debuggability. You cannot curl it or read a payload in a log. Tooling exists and is less universal, and on-call engineers at 3am notice this.
• Load balancing. HTTP/2 connections are long-lived and multiplexed, so a connection-level load balancer sends all of a client's requests to one backend. Correct balancing needs request-level (L7) awareness or client-side balancing, and getting this wrong produces badly skewed load that is confusing to diagnose.
• Third-party and partner integration, where JSON over HTTP remains the universal expectation.
• Ecosystem edges: some proxies, gateways, WAFs and monitoring tools handle gRPC less well.

Where JSON over HTTP breaks down

• Contracts drift without generated clients and enforced schemas — the failure is a field quietly renamed and a consumer breaking in production. Adding a schema registry and contract tests recovers most of gRPC's advantage, and is the honest comparison.
• Verbosity at high volume, where parsing cost becomes measurable.
• No native streaming or deadline propagation.

The reasonable position

gRPC for internal service-to-service communication where volume is high and contracts matter; JSON over HTTP at the edge, for partners, and for anything a browser or a human touches. This is what most large organisations converge on, and the boundary is usually the API gateway.

The decision is more about contract discipline than about bytes on the wire. A team with a schema registry, generated clients and contract tests over JSON has most of the benefit; a team using gRPC without those has bought a harder debugging story for a marginal performance gain.