Microservice communication: REST, gRPC and service mesh
In short: Microservices communicate synchronously with REST or gRPC, or asynchronously with events. Each remote call can fail, so use timeouts, retries and circuit breakers. An API gateway manages traffic from outside; a service mesh handles encryption, retries and telemetry between services.
Synchronous options
| Aspect | REST | gRPC |
|---|---|---|
| Transport | HTTP/1.1 or HTTP/2 | HTTP/2 |
| Payload | Usually JSON (text) | Protocol Buffers (binary) |
| Contract | Optional, often OpenAPI | Required .proto file |
| Streaming | Limited | Client, server and bidirectional |
| Browser support | Native | Needs a proxy such as gRPC-Web |
| Best for | Public APIs, simple integration | Fast internal service-to-service calls |
REST uses resources and standard HTTP methods, and is easy to test with curl. gRPC generates client and server code from a schema, so calls look like local functions and payloads are compact. Many organisations use REST at the edge and gRPC inside.
A gRPC contract looks like this:
syntax = "proto3";
service Orders {
rpc GetOrder (OrderRequest) returns (OrderReply);
}
message OrderRequest { string order_id = 1; }
message OrderReply { string order_id = 1; string status = 2; }Asynchronous events
Instead of calling the stock service, an order service can publish an OrderPlaced event and let interested services react (see message queues and event streaming). This removes runtime coupling, but makes flows harder to trace. Long business processes across services are often handled as a saga: a series of local steps with compensating actions if a later step fails.
Resilience patterns
A chain of synchronous calls is only as available as its weakest link. Protect every call:
- Timeouts so a slow dependency cannot hold threads forever.
- Retries with backoff and jitter, only for idempotent operations.
- Circuit breakers that stop calling a failing service for a while and fail fast instead.
- Bulkheads that limit how many resources one dependency can use.
- Fallbacks, such as cached data, when a non-critical service is down.
Services find each other through service discovery, such as Kubernetes DNS names, rather than fixed IP addresses.
API gateway and service mesh
An API gateway handles north-south traffic from clients: routing, authentication, rate limiting and request shaping. A service mesh, such as Istio or Linkerd, handles east-west traffic between services, typically with a sidecar proxy beside each service, or in newer designs a shared per-node proxy. It provides mutual TLS (mTLS), retries, traffic splitting for canary releases, and consistent metrics and traces without changing application code.
Tip: a mesh adds operational complexity. For a handful of services, libraries and a gateway may be enough; meshes pay off as service count and security needs grow.
From a security view, mTLS in a mesh gives each workload a verifiable identity, which supports zero trust policies such as "only the checkout service may call payments".
Practice
Why is gRPC often preferred for internal calls?
What does a circuit breaker do?
What is the difference between an API gateway and a service mesh?
Key takeaways
- REST suits public APIs; gRPC suits fast internal calls.
- Events reduce coupling but make flows harder to trace.
- Use timeouts, safe retries and circuit breakers on every call.
- Gateways manage client traffic; meshes manage service-to-service traffic.
- Mesh mTLS gives workloads identity for zero trust policies.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.