A file-sync company moves internal service communication from JSON over HTTP to gRPC. What improves, what gets harder, and where would you keep HTTP/JSON?

What improves

Payload size and serialisation cost. Binary encoding is substantially smaller and far cheaper to encode and decode than JSON. For a service graph handling large volumes of internal calls, serialisation is a measurable share of CPU, and this is a direct saving across the fleet.

Schema as a contract, enforced. The interface definition generates client and server code, so a field type mismatch is a compile error rather than a runtime surprise. In a polyglot environment this eliminates a whole class of integration bug — and it is usually the benefit teams value most after adoption.

Streaming as a first-class concept. Client, server and bidirectional streaming over one connection. For file sync specifically this matters: transferring a large file as a stream of chunks, or receiving a continuous stream of change notifications, is native rather than an HTTP workaround.

Connection multiplexing over HTTP/2, so many concurrent calls share one connection without head-of-line blocking at the application layer.

Deadlines built into the protocol. A deadline propagates automatically through the call chain, which is one of the most valuable resilience properties in a distributed system and is usually bolted on awkwardly with HTTP.

What gets harder

Debugging. You cannot read a binary payload from a packet capture or curl an endpoint casually. Tooling exists but is less ubiquitous, and the loss of "just look at the request" is a real productivity cost that engineers feel daily.

Browser support. gRPC does not work natively from browsers; a proxy translation layer is required. This alone usually decides the edge-versus-internal boundary.

Load balancing. gRPC uses long-lived HTTP/2 connections carrying many requests, so connection-level balancing distributes connections rather than requests — and one connection can carry vastly more load than another. This needs request-level balancing, a proxy that understands HTTP/2, or client-side balancing. Teams are frequently surprised by uneven load after adoption, and this is why.

Schema evolution discipline. Field numbers are permanent. Reusing a number after removing a field produces silent data corruption rather than an error, which makes review of schema changes genuinely important.

Operational tooling. Logging, tracing and gateway integrations all need gRPC-aware versions.

Where to keep HTTP/JSON

• Public and partner APIs, where broad client compatibility and ease of exploration dominate.
• Browser-facing endpoints.
• Webhooks and integrations, where the other side controls the client.
• Low-volume internal endpoints where the performance benefit is negligible and the tooling cost is not — admin interfaces, health endpoints, occasional operational calls.

The decision rule

gRPC for high-volume internal service-to-service communication in a polyglot environment; HTTP/JSON at the edge and wherever a human or an unknown client is on the other end. Most mature architectures run both, with translation at the boundary, and the mistake is treating it as a platform-wide either/or.