Skip to content

CONCEPT Cited by 1 source

Send what you use

Definition

Send what you use is the design principle that a producer of an RPC payload should include only the fields the receiver will actually consume, rather than shipping a union of fields and letting the receiver discard the unused ones. It is the payload-altitude analogue of C++'s include-what-you-use (IWYU) discipline for header files: ship exactly the dependencies the consumer requires, no more.

Canonicalised on the wiki from Pinterest's 2026-05-01 Feature Trimmer post (Source: sources/2026-05-01-pinterest-optimizing-ml-workload-network-efficiency-part-i-feature-trimmer), which names the principle explicitly: "If we could send only the required features and trim everything else, similar to C++'s 'include what you use' header management tool removing unnecessary #include's, we could potentially cut root-leaf network usage by ~50%."

The underlying shape

In any two-tier system where a producer builds a payload for a consumer, three payload shapes exist:

Shape Producer ships Consumer uses Waste
Send-everything union of all possible fields small subset union minus subset — potentially large
Send-what-you-use exactly consumer's required fields same fields none by construction
Send-per-consumer-tailored tailored per consumer instance same fields none + tailored to route

The Send-What-You-Use shape requires the producer to know (or be told) each consumer's required field set. That knowledge has to come from somewhere — typically a contract artefact the consumer publishes and the producer consumes.

The Pinterest instance

Pinterest's Feature Trimmer is the canonical production instance at ML-serving altitude:

  • Producer = root host building the per-candidate fan-out RPC for a leaf model.
  • Consumer = leaf model (specified by model name + version in the request).
  • Contract artefact = the model signature in module_info.json inside the .pt archive, declaring input_names the model will consume.
  • Result: root trims the fan-out payload to exactly the declared allowlist; remaining features are not serialised, not compressed, not transmitted. The network saving compounds the CPU saving from less SerDe work, which further reduces latency.

Pinterest's motivation framing makes the architectural observation explicit: "In our root–leaf architecture, the root is shared across many leaf partitions and must fetch ML features for all models. To minimize feature store QPS, the root fetches the union of features needed across models (per candidate Pin), stores them in an efficient in-memory cache, and then fans out the full feature set to each leaf model. Each model converts and uses only the features it needs; the rest are effectively discarded before inference." — the union-fetch + full-fan-out pattern is the Send-Everything shape; Feature Trimmer is the Send-What-You-Use upgrade.

Why it's the right lever vs compression

Compression — Pinterest's first lever, with fbthrift lz4 — reduces how many bytes the unused fields take on the wire but does not stop them from being serialised, compressed, transmitted, decompressed, and deserialised. Send-What-You-Use eliminates the work entirely. Pinterest's framing on the compression lever: "Compression was a solid early win, but it didn't change the underlying problem: we were still shipping too much unused data." (Compare concepts/compression-codec-tradeoff.)

Preconditions for the pattern to work

  1. A contract artefact declaring each consumer's required fields (Pinterest: module_info.json).
  2. A distribution mechanism to get the contracts to the producer (Pinterest: ride the model-deploy pipeline).
  3. A lookup mechanism on the producer to map request → consumer identity → allowlist (Pinterest: model-name + version → consolidated in-memory map).
  4. A safe fallback when the lookup fails (Pinterest: pass untrimmed).
  5. A stability invariant on the contract — the producer needs to trust the contract didn't change out from under it (Pinterest: signature version-stability, enforced socially by "if a signature modification is necessary … a new model is forked from the original").

Sibling patterns

  • IWYU for C++ headers — same principle at build-dependency altitude; declare exactly what you include.
  • Cherry-picked instrumentation payload — same principle at telemetry altitude; ship only the fields a given span consumer needs.
  • GraphQL field selection — same principle at API-response altitude; the client declares the fields it wants.
  • Protobuf FieldMask / gRPC partial responses — same principle at gRPC altitude; the client names the fields it wants in the response.
  • Columnar projection pushdown — same principle at query altitude; the storage engine sends only the columns the query selects.

All share the structural observation: the producer has the information to skip unused fields, if only it is told what the consumer needs.

Seen in

Caveats

  • Not the same as lazy loading — Send-What-You-Use operates at the RPC-payload altitude (what bytes go on the wire); lazy loading operates at the consumer altitude (what's materialised in memory once received). Both reduce work but at different stages.
  • Cost of building the contract is non-trivial — Pinterest's contract artefact is already produced by the training pipeline (as the PyTorch model signature), so the marginal cost was low. Systems without an existing contract-producing pipeline would have to build one.
  • Fails-over-safely is a deliberate choice — skip-on-missing-allowlist means an unknown model gets the old union-fan-out behaviour. Safer than blocking the request but does silently give up the network saving for that model.
Last updated · 445 distilled / 1,275 read