Cost, latency, quality

Cheap, fast, good. Pick two.

There is an old line about any job: you can have it cheap, fast, or good, but not all three at once. Routing lives inside exactly that bind. Every request pulls on three things at the same time: cost (what the call charges you), latency (how long the answer takes), and quality (how good the answer is).

The trouble is they pull against each other. The cheapest model is often the slower or weaker one. The fastest one may cost more. The best quality model is frequently the slow and pricey one. You rarely find a provider that is the cheapest, the fastest, and the best all at once. If you did, routing would be trivial; you would always pick it.

So routing is not about finding a perfect provider. It is about deciding, for this request, which of the three pulls matters most, and accepting that you give up a little on the others.

A weight turns "what I value" into "who serves this."

How does the gateway act on a preference like "I care more about speed than money"? It scores each provider with a weighted blend: take the provider's numbers, multiply each by how much you care about it, add them up, and the lowest total wins. The weight is just a dial that says how much each pull counts.

Before scoring, the gateway puts the numbers on the same scale. Cost is in dollars; latency is in milliseconds. You cannot add those directly. So it normalizes each one across the candidates: the best becomes 0, the worst becomes 1, the rest land in between. Now a cost score and a latency score are comparable, and a weight can mix them.

Drag the handle below. At one end the gateway cares only about cost; at the other, only about latency. Each card shows its score (lower is better), and the chosen provider lights up. Watch the winner change as you slide.

Score it by hand.

Take three providers. A is cheap but slow, B is fast but mid-priced, C sits in the middle on both.

The last two columns are the normalized scores: cheapest cost (A) is 0.0, priciest (C) is 1.0; fastest latency (B) is 0.0, slowest (A) is 1.0. Now blend them with score = w × cost + (1 - w) × lat, where w is the weight on cost.

Nothing about the providers changed between the two blocks. Only the weight moved, and the winner went from A to B. That is the whole job of a scoring router: turn one number that says what you value into one provider that serves the request.

There is no free lunch.

Notice what the weight does not do: it never gives you a provider that is best on every axis. When A wins on cost, you accepted its slow latency. When B wins on speed, you accepted its higher price. The weight does not escape the tradeoff. It just states, on the record, which side you are willing to lose on.

That is a feature, not a flaw. A good router does not pretend the tradeoff is gone. It makes the tradeoff explicit and consistent, so every request is decided the same honest way instead of by whoever's config got pasted last.

Key takeaways