Skip to content

PATTERN Cited by 1 source

SSE over gRPC for streaming aggregation

SSE over gRPC for streaming aggregation is the protocol- selection pattern of choosing Server-Sent Events (SSE) — a lightweight HTTP-based streaming protocol — over gRPC for inter- stage communication in high-throughput aggregation pipelines where the dominant traffic pattern is one-directional streaming of pre-aggregated data.

When to prefer SSE over gRPC

gRPC is the default choice for service-to-service communication. But for streaming large volumes of aggregated data between pipeline stages, SSE can be more appropriate when:

  • Traffic is one-directional (Stage N → Stage N+1), not request-response.
  • Messages are pre-aggregated (already serialised/compressed by the application), reducing the value of gRPC's Protobuf serialisation.
  • Connection pool management and per-stream metadata overhead in gRPC becomes a resource sink at high volume.
  • Memory pressure from gRPC streaming responses accumulates faster than the pipeline can drain them.

Netflix's experience (2026-07-13)

Netflix initially used gRPC for inter-stage communication in Service Topology's flow-log pipeline. At production scale:

  • Serialization overhead consumed more CPU than business logic.
  • Connection pool management added resource pressure.
  • Memory pressure from streaming responses compounded GC issues on hot nodes.

Replacing gRPC with SSE:

  • Minimal serialization — lightweight HTTP text protocol.
  • Natural backpressure integration — SSE + reactive streams work together cleanly.
  • Simpler connection model — fewer moving parts than gRPC's multiplexed streams.
  • Dramatic reduction in resource consumption on both sender and receiver sides.

"The lesson: industry best practices like 'use gRPC for service communication' don't apply universally. For streaming large volumes of pre-aggregated data, lighter-weight alternatives may be more appropriate. Measure, don't assume." (Source: sources/2026-07-13-netflix-building-service-topology-at-scale-architecture-challenges)

Trade-offs

gRPC SSE
Bi-directional ✓ ✗ (one-way)
Schema evolution Protobuf ✓ Manual
Observability tooling Rich ecosystem Basic
Overhead at high volume Higher Lower
Debugging Binary, opaque Human-readable

When gRPC is still better

  • Request-response RPC patterns
  • Bi-directional streaming with flow control
  • Schema-first API design with code generation
  • Lower volumes where serialization overhead is negligible

Seen in

Last updated · 585 distilled / 1,765 read