Skip to content

Product2026-11-082 min readFrom the project · Enterprise Data Gateway →

One official key, many subsidiaries — how to share it safely

A group had one key for a third-party data service and several subsidiaries that needed it. Instead of handing it out, I put a gateway in front. Notes on the trade-offs.

The request sounded simple at first: the group had bought a company-data service that came with a single official key, yet the business systems of several subsidiaries all needed to call it. The easiest answer is to hand the key to everyone — which is also the most dangerous one.

What goes wrong when you just share it

  • Uncontrolled cost: anyone can call it, and you only learn what was spent at the end of the month
  • Paying twice: a company that subsidiary A looked up yesterday is billed again when subsidiary B looks it up today
  • No traceability: when something breaks, you cannot tell which subsidiary or which system made the call
  • No way to stop the bleeding: if the key leaks, the only fix is to replace it, and every system goes down together

My approach: the key never leaves the building

The official key lives only inside the gateway. Subsidiaries receive sub-keys issued by the gateway. Each sub-key can be disabled or rotated on its own, so a leak affects one subsidiary and nobody else.

When a request comes in, it passes the risk checks first and then reads the cache:

text
subsidiary request
  → key check → IP allowlist → API scope → QPS limit → daily quota
  → read the group cache
      hit  → return directly, no official quota spent
      miss → honestly report "miss"

One counter-intuitive decision

On a cache miss, the gateway does not call the official API on the subsidiary's behalf. Only queries, manual refreshes and bulk warm-ups from the group console ever reach the upstream.

That gives up a little of the "ask and you get it" experience. In return, cost becomes completely predictable: official quota is consumed by the group side alone, and no amount of subsidiary traffic can blow through the budget. Combined with bulk warm-up, the companies people actually look up are already in the cache before they ask.

A few things worth deciding early

  • Fields need permissions too: each consumer is bound to its own field pack, so the same API returns a different set of fields
  • Quotas come in layers: subsidiary QPS, subsidiary daily requests, group daily quota and the contract total — four layers, each minding its own limit
  • Log what you block: requests stopped by the risk checks are written to the log as well, otherwise you lose half the picture when debugging

Looking back, the real value of this product was never "forwarding requests". It was turning something that used to depend on everyone behaving well into something you can configure, measure and audit.

陕ICP备2026005972号-2