Service communication is the exchange of requests and responses between application services. When an application is split into independently deployable services, those services need a reliable way to exchange messages. Communication failures can also affect data consistency, so separating services creates operational concerns that a shared runtime does not have. section 2.0 section 2.3
gRPC is one option for internal service communication. Services exchange messages defined with Protocol Buffers, and generated Go code helps implement the connection. Generated client stubs also make cross-language calls practical: a Python Checkout service, for example, can call a Java Payment service. Changes to service definitions can surface as client-side test failures. section 2.5 section 1.3
Choose the boundary deliberately:
- For browser-facing APIs, consider REST. An internal gRPC service may need a conversion layer or a compatible public API; Twirp is another option for exposing JSON requests. section 1.3
- For a simple application with only one or two services, weigh the cost of maintaining .proto definitions before adopting gRPC. section 1.3
- For distributed services, plan for timeouts, retries, circuit breakers, error handling, and TLS rather than assuming every call will succeed. section 6.0
Communication remains an operational concern after deployment. Metrics, logs, and alerts can reveal errors or performance problems between services, as well as problems involving databases and third-party APIs. Keep Protocol Buffer definitions and generated stubs in step with service changes; stub generation can be part of a CI/CD pipeline. section 1.4.4 section 3.0
