The Point

A gRPC Pusher is a message dispatch intermediary – it pulls messages from a Pub/Sub subscription and proactively pushes them to a target service’s gRPC endpoint. This solves the problem where workers cannot control which consumer processes which message.

Explanation

Why is this needed?

The testing pain point with worker-based services: a PRRC (PR Review Copy) environment and master share the same subscription. There is no way to guarantee that a test message will be consumed by the PRRC pod rather than a master worker – so every test requires manually deploying the commit image to master, which is cumbersome.

The gRPC Pusher solves this as an intermediary:

Pub/Sub Subscription
        ↓  pull
   gRPC Pusher (intermediary layer)
        ↓  push (can control which endpoint to route to)
  Target Service (specified gRPC endpoint)

The Pusher centrally pulls messages, then pushes them to a specified endpoint based on configuration – giving precise control over PRRC traffic without worrying about master workers stealing messages.

Configured via CRD

The Pusher’s behavior is managed through Kubernetes CRD config, which can set:

• Retry policy: retry strategy after failures (count, backoff)
• Traffic limit: rate limiting for pushes

Knowledge Sugar

Public implementations of this pattern

This “pull then push” message dispatch pattern is common in the industry:

• Knative Eventing: pulls from Broker/Channel, pushes to HTTP/gRPC sink endpoints, supports retry and dead letter sink, configured via CRD
• Dapr Pub/Sub: runs as a sidecar, pulls from various pub/sub backends, pushes to application endpoints via gRPC or HTTP
• GCP Push Subscription: GCP’s native push mode, sends messages as HTTP POST to a specified endpoint, supports exponential backoff retry

Core design concept: decoupling consume and process

Traditional workers couple “pulling messages from a subscription” and “processing messages” in the same process, making traffic routing hard to control. The Pusher separates the two:

• Pusher handles consume (single entry point)
• Target service only handles process (can be any endpoint)

This is also the core idea behind Dapr and Knative – extracting messaging infrastructure out of application logic.