Our Multi-Provider API Gateway, Measured: Alive But Quietly Stale

After actually using a multi-provider gateway in our own operations, the verdict is one line: "it never dies, but left alone it quietly goes stale." Calling our price gateway live, coingecko had failed with a 429 (too many requests) and was holding values about 25 hours old, yet the gateway did not stop - it fell back to the live sources and kept serving 718 coins. Availability was preserved, but the price was freshness.

In one line: a multi-provider gateway is a power strip. If one outlet (source) dies, the lights stay on. The danger is unknowingly drawing old electricity (stale values) from the dead outlet - so "quiet staleness" is more dangerous than an outright crash.

First, the terms. Fallback means automatically switching to another source when one fails, 429 is the rate-limit response for "too many requests," and freshness is when a value was last updated (that is, its age).

What does the gateway actually do?#

It unifies several external APIs behind one interface and auto-fails-over dead sources. Measured state: upbit 267 coins (OK), coinmarketcap 498 coins (OK), coingecko 495 coins (429 failed, stale). Combined, it serves 718 deduped coins through one window. If a source drops, the caller changes no code - that is the gateway's core value. But sources carry different fields: comparing BTC, coinmarketcap returned KRW as null and gave only USD. Unless the gateway normalizes currencies and fields, the caller hits blanks.

What was the biggest limit in practice?#

That freshness differs per source, but coming out one window hides it. For the same BTC, fresh upbit was about 89.32M KRW while 25-hour-stale coingecko was about 92.88M KRW - a measured ~4% gap that came purely from "age," not price movement (cache age, not the market). In USD too, upbit 58,600 / cmc 58,492 / coingecko 60,235 - about a 3% spread across sources. So when you use a gateway you must always read ok and freshness (last-poll time) together. Otherwise you trust "200 means fine" and use stale values.

Can you trust derived metrics?#

Be careful - a derived value inherits the age of its oldest source. Measuring the kimchi premium gave BTC -3.83%, but that was computed as fresh upbit divided by 25-hour-stale coingecko. So much of that "-3.83%" is not a real Korea-vs-US price gap but a staleness artifact. The memory side showed similar debt: curator stats list 8,882 facts of which 6,746 (about 76%) are stale candidates, with 8,084 awaiting verification - intake outran verification. The gateway gathers data, but "as of when" and "is it verified" stay the caller's responsibility.

So when do you use it, and when do you watch out?#

The key is a habit of separating availability from freshness.

• Use it: when you do not want to be shaken by one API's outage or rate limit. Even at 429, the whole does not die.
• Watch out: for values where freshness is life, like prices or arbitrage. Gate on ok and freshness and explicitly exclude stale sources.
• For derived metrics (premiums, averages), label the age of the input sources and hold the calculation when one side is old.

Reference links#

• Model Context Protocol (tool integration standard)
• ccxt (unified multi-exchange API)
• httpx (async HTTP client)
• tenacity (429 retry/backoff)
• pybreaker (circuit breaker)

Note: figures are a live snapshot from 2026-06-30 to 07-01 and shift every moment with prices and source state (not permanent numbers). The coingecko 429 and 25-hour staleness reflect that moment's free rate-limit situation, and freshness and gaps change on the next call. Gateway behavior depends on source mix and policy, so check status yourself.