Sync vs Async: REST vs gRPC vs Messaging
Fast recall
Quick revision
Core answer
Pragmatic understanding of communication patterns and when each applies
Using REST everywhere (slow internal calls) or async everywhere (complex for simple queries); ignoring gRPC because 'we know REST'
Discuss latency budgets, payload size impact, streaming vs request-response, browser/mobile constraints, HTTP/2 multiplexing, and when to mix all three in one architecture
Interview-ready guide
Interview answer
Three distinct communication patterns in microservices, each optimized for different situations.
REST over HTTP/JSON — the ubiquitous default
- Verbose but self-describing; cacheable at HTTP layer; debuggable with curl
- Works everywhere: browser, mobile, CLI, any language
- JSON schemas weak by default; OpenAPI helps
- Synchronous request-response
- Higher latency (3 to 5x vs gRPC); larger payloads (3 to 10x vs Protobuf)
- Best for: public APIs, B2B integrations, browser/mobile, infrequent internal calls
gRPC — HTTP/2 plus Protobuf
- Binary, compact, strongly typed schemas compiled into client and server stubs
- HTTP/2 multiplexing means many RPCs share one TCP connection
- Four modes: unary, server streaming, client streaming, bidirectional
- Polyglot-friendly; Java, Go, Python, Node all first-class
- Best for: internal service-to-service with strict latency SLOs, streaming use cases
- Downsides: limited browser support (needs gRPC-Web proxy), harder debugging, schema evolution discipline
Async messaging — Kafka, RabbitMQ, SQS, NATS
- Publishers write to broker; consumers read when ready
- Durability, retries, fan-out, backpressure handled by broker
- Decouples producer and consumer in time
- Best for: event-driven architectures, workflows, bulk processing
- Eventual consistency; ordering guarantees only within partitions
When to use each
REST at the edge
- Browser and mobile clients; B2B partners; public APIs
- Anywhere simplicity beats optimization
- CDN caching works natively
gRPC internally
- High-traffic service-to-service calls
- Strict latency budgets (p99 under 10ms)
- Polyglot teams needing type safety
- Streaming: live telemetry, chat, financial feeds
Async messaging for events
- Fan-out: OrderPlaced goes to email, analytics, warehouse
- Cross-team decoupling; producer doesn't know all consumers
- Bursty traffic; broker buffers spikes
- Long-running workflows
The real-world pattern
- REST at API Gateway (terminating from clients)
- gRPC between internal services
- Kafka or similar for events and async workflows
- All three coexist; each serves its purpose
Common mistakes
- REST everywhere: 5-hop internal chain at 20ms each equals 100ms baseline; gRPC cuts this to 20ms
- Async everywhere: user clicks Submit Payment, wants immediate success/failure, not async ack
- gRPC for public API: partners don't have tooling; browser needs proxy
- Huge JSON payloads: 10MB responses kill performance; use streaming or pagination
Key trade-offs
- gRPC performance claims are real but depend on context; low traffic barely differs
- HTTP/2 multiplexing is gRPC's biggest operational win (connection efficiency)
- Debugging gRPC requires grpcurl plus good observability
- Async adds eventual consistency; UX designs must accommodate
- Event ordering is per-partition only; key by entity for related events together
- Idempotency required on async consumers; at-least-once means duplicates
gRPC deadlines are elegant
- Deadline passed through call chain; if A sets 5 seconds, B calls C with remaining 4 seconds
- Much cleaner than per-hop timeouts
Protobuf schema evolution discipline
- Adding fields is safe; removing or renumbering breaks compat
- Use reserved keyword for removed field numbers
- Schema registry catches breaking changes in CI
The 80/20 rule
- 80% of internal calls fine with REST (simplicity wins)
- 20% of hot paths benefit from gRPC (latency budget)
- Events for cross-team decoupling and fan-out
- Don't convert everything to gRPC just because it's faster
The strategic answer
- Pick the pattern that matches the use case
- Mix and match; no religious war
- REST at edge, gRPC internal, events for decoupling
- Measure before optimizing; profile-driven, not dogma-driven
Sync vs Async: REST vs gRPC vs Messaging
Direct Answer
Three distinct models for microservice communication: REST/JSON is the default for external APIs and loose coupling — human-readable, cacheable, ubiquitous, but verbose and schema-lite. gRPC is best for high-performance internal RPC — HTTP/2, Protobuf (5–10x smaller, faster), streaming support, generated stubs; weaker browser support and harder debugging. Async messaging (Kafka/SQS/RabbitMQ) is best for event-driven decoupling, durability, and backpressure — services don't wait; but adds complexity, eventual consistency, and ordering concerns. Rule of thumb: REST at the edge, gRPC between high-traffic internal services, async messaging for events and long-running workflows.
Common Mistakes & Pitfalls
Using REST everywhere (slow internal calls) or async everywhere (complex for simple queries); ignoring gRPC because 'we know REST'
Check your understanding
Answer these without looking back at the article.
- How does gRPC-Web work and what are its limitations?
- What is Protobuf field number reservation and why does it matter?
- How do you handle request cancellation and deadlines across gRPC service chains?
- What are the consistency implications of mixing sync gRPC with async events?
Related interview prep categories
2Want a guided curriculum order?
These modules are also sequenced in our flagship backend interview track — open it when you prefer an ordered path instead of browsing by topic.