Backend API Routing

Problem Statement

Route the network from end-users to first and second-degree internal servers, minimizing latency while maintaining low cost and a reliability SLA.

Full example scenario

A backend engineer is tasked with optimizing the configuration and routing rules of an API gateway to ensure efficient handling of requests, reduce latency, and improve the reliability of backend services. The gateway routes incoming requests to five backend services (A, B, C, D, E), each with its own average processing time, reliability rate, and cost per request; from there, requests are routed on to a second layer of internal gateways (F through N), over a set of specific valid routes, each with its own additional processing time and additional reliability. Which percentage of traffic should go to each backend service, and from there to each internal gateway, in order to minimize total latency?

  • The weighted reliability of the backend services must be at least 99.5%.

  • The weighted reliability of the backend-to-gateway routes must be at least 99.5%.

  • The routing percentages into the backend services must sum to 100%, with no single service taking more than 40%.

  • For each backend service, its outgoing routes to internal gateways must sum to 100%, with no single route taking more than 75%.

  • The average cost per request across the whole system must not exceed $0.40.

  • The backend services data can be found in network_routing_backend.csv, with the columns Service,Average Processing Time (ms),Reliability (percentage),Cost per Request ($).

  • The valid routes from backend services to internal gateways can be found in network_routing_internal.csv, with the columns Backend Service,Internal Gateway,Additional Processing Time (ms),Additional Reliability (percentage).

What an optimal solution looks like

Entry traffic → backend services → internal gateways.

Service B Service C Service D

Entry gateway

100% of traffic

36.67% 23.33% 40.00%

Service A

0% · 200ms · 99.9%

Service B

36.67% · 150ms · 99.6%

Service C

23.33% · 100ms · 99.0%

Service D

40.00% · 120ms · 99.7%

Service E

0% · 180ms · 99.8%

27.50% 9.17% 17.50% 5.83% 30.00% 10.00%

Gateway F

0%

Gateway G

0%

Gateway H

27.50% of traffic

Gateway I

9.17% of traffic

Gateway J

0%

Gateway K

17.50% of traffic

Gateway L

5.83% of traffic

Gateway M

10.00% of traffic

Gateway N

30.00% of traffic

Built with Modeler

The problem above is stated as a single shot: you hand over the whole problem and get a model back. Modeler takes the other route — you start with the business question you actually have, and it works with you until the problem is pinned down, the data is in, the code runs, and the answer holds up when the problem changes.

The tabs below walk the same API gateway routing problem through that route, one Modeler capability at a time.

Instead of writing the whole prompt up front, you start with the business question you actually have. Modeler searches the knowledge base, asks one clarifying question at a time — always the most important one first — and tells you which parts of the model are still missing. The options it offers come from examples in the knowledge base and from how similar problems are usually modeled in your industry, so you can answer with a number instead of prose.

We run an API gateway that routes incoming requests to a set of backend services, and from there some of the traffic gets routed on to a second layer of internal gateways. We want to decide what percentage of traffic to send where, to minimize overall latency, while keeping things reliable and within budget. Can you help me build a model for this?

This is a two-layer traffic routing problem. Before anything else I need the topology: how many entry points there are, and whether every backend service can reach every internal gateway or only some pairs are valid — that shapes which decision variables even exist.

Great topic, Orhan! This is a well-suited problem for mathematical optimization. Let me ask you a few focused questions to build out a complete and accurate specification.

Q1: Can you describe the two-layer network structure in a bit more detail?

  1. Layer 1 — Is there a single entry-point API gateway, or could there be multiple?

  2. Layer 2 — Is the routing from backend services to internal gateways always a possibility, or only for certain service-gateway pairs?

There’s a single entry-point gateway. It splits traffic across 5 backend services (A, B, C, D, E), each with its own average processing time, reliability rate, and cost per request. From there, only specific (backend service, internal gateway) pairs are valid routes — not every service can reach every gateway. We want to minimize total expected latency, subject to: weighted backend reliability at least 99.5%, weighted route reliability at least 99.5%, backend allocations summing to 100% with no single service over 40%, each service’s outgoing routes summing to 100% with no single route over 75%, and average cost per request at most $0.40.

One more thing - can we also make sure no single internal gateway ends up receiving more than 60% of all traffic overall, since some of our internal gateways have limited capacity? We’re worried about overloading one of them even if the per-route percentages look fine individually.

Topology, five constraints and a sixth volunteered gateway-load cap are all recorded now. What’s still open is exactly how “total latency” should be computed across two hops — that has to be pinned down precisely before an objective function can be written.

Good, the spec is taking shape. Now I need to understand exactly how latency is calculated so the objective is precise.

Q2: How should total expected latency be computed across the two layers?

  1. Sum of both hops — backend processing time plus the route’s additional time, weighted average across all full paths.

  2. Backend layer only.

  3. Gateway layer only.

  4. Weighted sum with a priority factor.

Option 1 - sum of both hops, weighted average total per-request latency across the full entry->backend->gateway path.

That fixes the objective’s shape, but it raises a second question the user hasn’t specified yet: what exactly does “weighted” mean here? A route’s share of its own service’s traffic is not the same number as its share of all traffic — and the reliability and gateway-load constraints both depend on which one is meant.

One more important clarification before we move to implementation.

Q3: For the backend-to-gateway reliability constraint, how should the weighting work?

  1. Full-path weighting — weight each route’s reliability by its share of total traffic (backend allocation x route allocation).

  2. Within-service weighting — average each service’s routes independently, then average those across services, treating each service equally regardless of traffic volume.

Option 1, full-path weighting - that’s the correct way to think about it.

The specification is now complete and fully consistent with everything you have described.

Objective: Minimize weighted average end-to-end latency per request (backend processing time + route additional time), weighted by full-path traffic share.

Constraints captured: backend allocations sum to 100% and cap at 40%; weighted backend reliability >= 99.5%; weighted average cost <= $0.40; per-service route allocations sum to 100% and cap at 75%; weighted route reliability >= 99.5% (full-path weighted); no internal gateway above 60% of total traffic.

Are you happy with this specification, or would you like to adjust anything before I move on to the model implementation?

Modeler updates the specification after every answer, even while it is still incomplete — so you can always see what it has understood and what it is still waiting on. Choosing full-path weighting in Q3 is what turns this into a genuinely harder model than it looks: two decision layers multiplied together means the reliability, cost and gateway-load constraints are no longer simple linear sums, a point the Formulation on demand tab returns to.