A telemetry platform must choose between HTTP/JSON and gRPC for high-volume ingestion from thousands of agents. What actually decides it?

What genuinely favours gRPC here

• Serialisation cost at volume. For high-frequency telemetry, encoding and decoding dominates CPU. A binary format is several times cheaper than JSON, and at ingestion scale that is a direct infrastructure cost.
• Payload size, which is bandwidth and therefore money, particularly for agents on customer networks.
• Streaming over a single connection, avoiding per-request overhead for a continuous flow.
• A schema that is enforced, which for a telemetry contract consumed by thousands of agent versions is a meaningful correctness property.

What favours HTTP/JSON

• Debuggability. An engineer can reproduce a request with a command-line tool and read the payload. At 3am this matters more than most architectural properties.
• Compatibility. Proxies, load balancers, firewalls and corporate networks handle it universally. gRPC requires HTTP/2 end to end, which some corporate middleboxes still break.
• Client ecosystem. Any language, any environment, no code generation step.
• Simplicity for low-volume paths. Configuration, control and management APIs gain nothing from binary encoding.

The decision that is usually right

Both, at different boundaries. gRPC for the high-volume agent-to-ingester path where efficiency dominates and both ends are controlled. HTTP/JSON for the query API, the control plane and anything third parties integrate with.

This is not indecision; it is recognising that the ingestion path and the API path have different requirements, and forcing one protocol across both optimises for whichever is louder in the design meeting.

The consideration that overrides both

Whether you control the client. If agents are yours and update automatically, protocol changes are manageable and efficiency should win. If clients are third-party and long-lived, compatibility and debuggability dominate, and the ability to make a request with a text editor is worth real CPU.