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.

BFF (Backend For Frontend) is an architecture pattern where you build a dedicated backend layer for each frontend client, instead of having all clients share a single API.

Explanation

Why do you need BFF?

Different clients have very different data needs. Take an e-commerce platform as an example:

• Mobile app: small screen, limited bandwidth, needs only a few compact fields
• Web browser: can show richer data, needs more fields
• Third-party partners: yet another set of data format requirements

With a single shared API, two problems arise:

• Over-fetching: returning fields the client does not use
• Under-fetching: one request is not enough, so the client sends multiple requests

BFF adds a layer between clients and backend microservices:

Mobile App  →  Mobile BFF  ┐
Web App     →  Web BFF     ├─→  microservices
Partner API →  Partner BFF ┘

Each BFF handles:

1. Aggregating responses from multiple microservices (one request instead of many)
2. Trimming data to the format that specific client needs
3. Client-specific logic (e.g. mobile pagination)

Who maintains the BFF?

Usually the frontend team, so they can adjust the API format on their own without waiting for backend changes.

Knowledge Sugar

BFF vs API Gateway

These are easy to confuse, but they serve different purposes:

In practice they can coexist – the API Gateway sits in front handling common concerns, while BFFs sit behind it doing client-specific data aggregation.

When do you not need BFF?

• Only one client type (e.g. web only)
• The backend is a monolith with nothing to aggregate
• The team is small and maintaining multiple BFFs costs more than it saves