Why we moved from REST to gRPC internally

Our public API stayed REST, but every internal service-to-service call moved to gRPC over the course of a quarter. Here’s why it was worth the migration cost.

The JSON tax was real

Profiling showed a surprising chunk of CPU time going to marshaling and unmarshaling JSON on our highest-traffic internal paths. Protobuf’s binary encoding and generated structs took that cost down to nearly nothing.

Contracts, not conventions

The bigger win wasn’t performance — it was that .proto files became the enforced contract between teams instead of a wiki page nobody updated. Breaking changes now fail at compile time instead of at 2am.

What we kept in REST

Anything client-facing or webhook-based stayed REST/JSON on purpose — gRPC’s tooling story for browsers and third-party integrators isn’t worth the trade-off outside the service mesh.