Choosing RPC, gRPC, or Event APIs for Service Integration

Introduction

Services can communicate through request-response calls or by publishing work and events for later processing. REST-style HTTP, gRPC, and event APIs make different trade-offs in latency, coupling, typing, delivery guarantees, and operational complexity.

Consider a checkout service that must tell a customer whether stock was reserved. That needs a request-response call. An OrderPlaced event can let analytics and fulfillment react after checkout without making the checkout wait for them.

The sections below compare when each approach fits. They also cover reliable event publication with an outbox, duplicate handling, observability, and the failure cases teams should plan for.

gRPC: typed RPC with generated clients

gRPC uses Protocol Buffers to define services and messages, then generates client and server code. It supports unary calls and streaming patterns, and its compact binary encoding can suit internal service traffic. The schema makes many changes visible during development, but teams need code generation, version compatibility practices, and tooling for debugging binary payloads. Browser use often requires gRPC-Web or a gateway, so it is not automatically the best public interface.

Events: publish that something happened

An event such as OrderPlaced records a fact that consumers can process independently. The producer does not need to know every consumer, and consumers can handle work asynchronously. Events are useful for notifications, fan-out, and workflows that should survive temporary consumer outages. They introduce eventual consistency, duplicate delivery, ordering questions, schema evolution, and more operational machinery. An event should state what happened, not pretend the producer can guarantee every subscriber completed work.

Reliable event publication with an outbox

An event-driven service often needs to update its database and publish an event for the same operation. If it commits the database change first and crashes before publishing, consumers never hear about the change. If it publishes first and the database transaction later rolls back, consumers see an event for work that did not happen. These are two sides of the dual-write problem.

A transactional outbox records the event in the same database transaction as the domain change. A separate publisher reads pending outbox rows and sends them to the broker, then marks them delivered. The publisher can send a row more than once if it crashes between publish and acknowledgement, so consumers still need an event ID, deduplication, and idempotent effects. The outbox closes the gap between the service’s database write and its publication intent; it does not create exactly-once delivery across the whole system.

flowchart TD
    A[Need an interaction] --> B{Must caller wait for result?}
    B -->|Yes| C{Typed internal service contract?}
    C -->|Yes| D[gRPC or typed RPC]
    C -->|No| E[HTTP JSON request-response]
    B -->|No| F[Publish event or command]
    F --> G[Consumers process independently]

When to use and when not to use

Use HTTP/JSON for public APIs, browser clients, and integrations where broad tool support matters. Use gRPC when services need strongly typed contracts, efficient internal calls, or streaming and your stack supports the tooling. Use events for decoupled asynchronous work and fan-out. Avoid choosing gRPC solely because binary sounds faster, or events solely to avoid designing a synchronous contract. For a simple operation requiring an immediate answer, events can make the product flow harder than it needs to be.

Trade-off analysis

Implementation snippet

A typed service definition makes the RPC boundary explicit. A JSON event should also have a stable name and schema version:

syntax = "proto3";
service Inventory {
  rpc Reserve (ReserveRequest) returns (ReserveReply);
}
message ReserveRequest { string sku = 1; int32 quantity = 2; string request_id = 3; }
message ReserveReply { bool reserved = 1; string reservation_id = 2; }

For an event path, include a unique event ID, occurrence time, aggregate ID, and schema version. Consumers should deduplicate by event ID and make processing idempotent. Do not use a request ID as a substitute for a durable event identity.

Production failure scenarios and mitigations

A synchronous chain of five services exceeds the caller’s deadline; set per-hop budgets and reduce unnecessary hops. A gRPC schema renumbers a field that was previously shipped; never reuse field numbers and reserve removed ones. A broker delivers an event twice; deduplicate and make the handler idempotent. Consumers process related events out of order; partition by aggregate key or include sequence numbers and define handling. A public browser cannot call native gRPC; expose a compatible HTTP gateway or use a different contract.

Observability checklist

• For RPC: record method, status, deadline exceeded, and dependency latency with trace context.
• For gRPC: monitor call status codes, stream duration, and generated client versions.
• For events: track publish failures, queue lag, delivery attempts, dead-letter counts, and consumer age.
• Correlate request and event IDs without logging message secrets or personal data.

Security notes and pitfalls

Authenticate and authorize every RPC; internal network location is not identity. Protect brokers with scoped producer and consumer permissions, encrypt transport, and validate message schemas at boundaries. Events can contain personal data that outlives the source record, so define retention and deletion behavior. Common pitfalls include assuming exactly-once delivery, unbounded retries, incompatible schema changes, hidden synchronous calls inside event consumers, and overlooking browser or proxy support.

Quick Recap Checklist

• Choose synchronous RPC when the caller needs the result before continuing.
• Choose events when producers and consumers can progress independently and eventual consistency is acceptable.
• Confirm client environments support the chosen transport and generated-code workflow.
• Define timeout, retry, schema evolution, and observability policies for the integration.
• Assume event delivery can repeat and make consumer effects idempotent or deduplicated.

Interview Questions

Further Reading

• API contracts and consumer expectations — Define compatibility rules for clients and services.
• Sync, async messaging, and webhooks — Compare common ways to deliver work and notifications.
• Partial failure, ordering, and eventual consistency — Plan for delays and failures across distributed services.
• gRPC: Core concepts — RPC calls, streaming, deadlines, and service definitions.
• AsyncAPI Specification — Describe event-driven APIs and message channels.
• CloudEvents Specification — A common envelope for event metadata across systems.

Conclusion

Choose the interaction first, then choose the interface. Synchronous APIs fit work that needs an answer; event APIs fit work that can continue independently, provided the team plans for eventual consistency and duplicate delivery.