perf(routing): batch the session and PML Decision Engine evaluations
@jagan-jaya asked for a batch call: parallelising the per-wallet-type
evaluations hid the latency but left the call volume -- N requests and N
rule lookups per session request.
Session tokens and payment method list pre-routing now send one
`routing/evaluate/batch` request carrying every wallet type's parameter
set. The engine resolves and parses the active algorithm once and
evaluates it N times, so a cut-over profile with three wallet types costs
one round trip and one rule lookup instead of three of each. Results come
back positionally; an entry the engine could not evaluate is an empty
list, mirroring how callers already treat a failed single evaluation.
Deploy ordering is soft: against an engine without the endpoint the batch
call fails once and degrades to the existing concurrent single
evaluations, so Hyperswitch can ship first and the batch activates when
the engine does (paired change: juspay/decision-engine batch-evaluate PR).
The shadow path is batched too, which is where most of the volume was --
it runs for every merchant with the flag on, not just cut-over ones. One
spawned task per request now carries all wallet types and logs one diff
per type, replacing a spawned task per type. The per-type shadow spawn
helper is gone; `perform_session_routing_for_pm_type` hands its shadow
entry back to the caller instead of spawning, and its fallback-config
fetch is back to the no-algorithm case only.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
hyperswitch
7b208ef0 - perf(routing): batch the session and PML Decision Engine evaluations
