Running Optimization Models in Production

An optimization model that works in a notebook is perhaps a third of an optimization system. Production adds the unforgiving parts: the solver must return something useful within a deadline, infeasible inputs must produce diagnoses rather than stack traces, results must be reproducible enough to debug, and the whole thing needs tests and monitoring. This page collects the operational patterns for running MILP and CP-SAT models inside real software.

The solve-call contract: what the caller is promised

Design the optimization service around an explicit contract, because solvers have more outcomes than "answer" and "error":

OPTIMAL — proven best solution.
FEASIBLE / time-limit hit — an incumbent solution with a known optimality gap. Usually still shippable.
INFEASIBLE — no solution exists for these inputs; the response should say why (see below).
UNBOUNDED / error — almost always a model or data bug, not a real condition.

The API returning {status, solution?, gap?, diagnostics?} forces every caller to handle the feasible-but-not-proven case, which is the normal case at scale.

Time limits and MIP gaps: define "good enough" numerically

Never run a MIP uncapped in a service. Set both a wall-clock limit and a relative MIP gap (stop when incumbent is within x% of the bound) — whichever hits first ends the solve:

Planning runs: gap 0.1–1% with a generous limit.
Interactive/near-real-time: firm time limit (seconds), accept whatever gap results, and report it.

MIP solve-time distributions are heavy-tailed: the same model that solves in 10 s on Monday's data can run for hours on Thursday's. The gap-plus-limit pattern converts that tail risk into a bounded-latency, bounded-quality trade you chose deliberately. Log the achieved gap on every solve — a drifting gap is your earliest signal that instances are outgrowing the formulation.

Warm starts: reuse yesterday's solution

When consecutive solves see similar data (rolling-horizon planning, re-optimization after a disruption), feed the previous solution as a MIP start. The solver begins with an incumbent, enabling immediate pruning; speedups of 2–10x are routine, and solution stability improves — plans do not churn gratuitously between runs, which planners care about as much as optimality. Every serious solver and modeling layer supports it (variable .start values, cp_model solution hints). The previous solution may be infeasible under today's constraints; solvers repair partial starts, so pass it anyway.

Diagnosing infeasibility: IIS and elastic constraints

"INFEASIBLE" with no explanation is unshippable. Two standard tools:

IIS (Irreducible Infeasible Subsystem). Gurobi/CPLEX/SCIP can extract a minimal set of mutually contradictory constraints — the smallest story of the conflict ("demand_paris + capacity_lyon + maintenance_window"). Map constraint names to human language and surface that.
Elastic (soft) constraints. Add slack variables with heavy penalties to constraints that are allowed to bend in emergencies. The solve then always succeeds, and nonzero slacks are the diagnosis: "this plan requires 40 overtime hours at plant 2." Choose penalties orders of magnitude above real costs, and tier them if some constraints must yield before others.

The elastic pattern doubles as the graceful-degradation strategy: the service returns a plan plus violations, and humans decide.

Determinism and reproducibility

To debug "why did Tuesday's run pick that plan," you must be able to re-run it. That requires pinning: solver version, model/data snapshot, random seed, thread count, and time limit — because MIP solvers are only deterministic when all of these are fixed. Two traps: wall-clock time limits make runs machine-load-dependent (some solvers offer deterministic work limits instead — CP-SAT and CPLEX do); and changing thread count changes the search trajectory legitimately. Archive the LP/MPS file and solver log for every production solve; storage is cheap and the log contains the gap trajectory you will want later.

Testing optimization systems

Optimization code fails silently — a wrong sign produces plausible-looking suboptimal plans, not exceptions. Layer the tests:

Known-optimum fixtures. Tiny instances (hand-checkable, 3–10 variables) with exact expected objectives, solved to optimality in milliseconds in CI.
Solution validators. An independent function that checks a returned solution against every business rule without using the solver. Run it on every production solve too, not just in tests — it is your defense against model/reality drift.
Metamorphic properties. Add capacity → objective must not worsen; scale all costs 2x → objective doubles; remove an unused resource → solution unchanged. These catch formulation regressions without knowing optima.
Golden-instance regression. A fixed corpus of realistic instances; alert when objective or solve time drifts beyond tolerance across code or solver upgrades.

Monitoring solve health

Dashboards for an optimization service track: solve time distribution (watch the tail), achieved gap, incumbent-found time, infeasibility rate and which constraints' slacks activate, and objective value over time. A slow upward creep in solve time usually means instance growth is approaching a formulation cliff — the trigger to revisit formulation tightness before the pager goes off.