Ingestion Layer → Protocols Supported

gRPC

The high-throughput binary protocol used by server-side callers that need lower overhead than JSON-over-HTTP at scale.

High-Level Design

gRPC is the opt-in transport for the platform's highest-throughput producers.

Data Source
High-Throughput Server Callers
IoT gateways, internal services
→
Ingestion
gRPC Endpoint
Protobuf-based streaming ingress
→
Processing
.NET Core Ingestion API
ASP.NET Core gRPC service
→
Foundation
Azure Event Hubs
Hand-off after acknowledgment
→
Intelligence
Azure Monitor
Throughput and consumer-lag dashboards
→
Activation
IoT Hub Bridge
The primary consumer of this transport

💼 Business Context

  • Matters for a small number of very high-volume server-side integrations (IoT gateways, internal event buses) where JSON overhead becomes measurable at scale
  • Reduces bandwidth and CPU cost for the highest-throughput producers
  • Owned by Platform Engineering; opt-in, not the default

🔌 Technical Overview

The Ingestion API exposes a gRPC service alongside the REST endpoint, using the same event schema compiled to Protocol Buffers. gRPC's binary encoding and HTTP/2 multiplexing reduce per-event overhead and allow a single connection to stream many events, which matters for producers emitting tens of thousands of events per second — most notably the IoT Hub-to-Ingestion-API bridge described under IoT Devices.

Used By

IoT gateways High-volume internal services Batch import jobs

💾 Protobuf Contract Excerpt

service Ingestion {
  rpc TrackEvent(EventRequest) returns (EventAck);
  rpc TrackEventStream(stream EventRequest) returns (stream EventAck);
}

🔗 Integration Points

  • gRPC service on the .NET Core Ingestion API (ASP.NET Core gRPC support)
  • Protocol Buffers schema — compiled from the same source contract as the REST/JSON schema
  • Used by the IoT Hub bridge and other high-throughput server-side producers
  • Azure API Management — gRPC-aware routing where supported, or direct AKS ingress for internal callers

🧰 Services Consumed

⚠️ Non-Functional Considerations

  • Scale: streaming RPCs let a single connection carry sustained high-throughput traffic without per-request HTTP overhead
  • Latency: lower per-event latency than JSON/HTTP at high volume due to binary encoding and connection reuse
  • Reliability: bidirectional streaming allows the server to signal backpressure to the client directly
  • Security/Privacy: mTLS between internal callers and the gRPC endpoint; external gRPC access is not exposed publicly

🎯 Enterprise Example

The IoT Hub bridge switches its highest-volume device fleet from HTTP to gRPC streaming, cutting ingestion-tier CPU usage by roughly a third at the same event volume — meaningful at millions of devices reporting continuously.

← Back to Protocols Supported