A real-time platform uses gRPC internally and REST externally. Where exactly should the boundary sit, and what belongs at the translation layer?

Why the boundary is at the public edge

The two protocols optimise for different things, and those things map exactly onto internal versus external traffic.

Internally, calls are high-volume, machine-to-machine, and between services you control and deploy together. gRPC's advantages apply directly: compact binary encoding, cheap serialisation, an enforced schema across languages, native streaming, multiplexing, and deadlines that propagate automatically through the call chain.

Externally, clients are browsers, mobile apps, partner systems and developers exploring with curl. They need broad compatibility, human-readable payloads, and ubiquitous tooling. gRPC does not work natively from browsers, which alone settles the question for most consumer platforms.

What belongs at the translation layer

Protocol translation — REST and JSON outward, gRPC inward.

Authentication and coarse rate limiting, established once at the edge so every internal service receives an authenticated principal rather than re-implementing verification.

Model shaping. This is the part teams skip and regret. The public contract must be deliberately different from the internal one. If the gateway mechanically exposes internal message definitions, every internal refactor becomes a breaking public change, and the platform has accidentally published its implementation.

The translation layer is an anti-corruption layer in both directions: it protects external clients from internal churn and protects internal services from having to preserve public contracts forever.

Public error taxonomy. Internal status codes map to a stable, documented external error model. Leaking internal error detail is both an information disclosure risk and a contract you did not intend to make.

What does not belong there

Business logic. A gateway accumulating domain rules becomes a distributed monolith that every team must change and nobody owns.

Idempotency. The key must be recorded in the same transaction as the effect it protects, and the gateway does not participate in that transaction. A gateway can deduplicate concurrent in-flight requests; it cannot guarantee atomicity. Implemented there, the property is usually true and occasionally not — which is worse than not claiming it.

Fine-grained authorisation, which needs domain state the gateway does not have.

The real-time complication

For a platform whose primary client interaction is a persistent connection, the boundary is different again: the WebSocket gateway is itself the translation layer, converting a stateful client protocol into internal service calls. That gateway is stateful, which means it cannot be deployed or balanced like the REST edge — a distinction that must be reflected in the infrastructure rather than discovered during a deployment.