←
Build the decisionSaved automatically
Medium · Grade 421. Peak Hour Payment Switch

Route payments through Friday afternoon peak traffic, degraded providers, and unexpected outages.

Scenario

Heavy transaction volume fills provider capacity while latency spikes, outages strike without warning, and payment deadlines tick down.

Problem statement

It is Friday afternoon at YamusaPay—the busiest traffic window of the week. A heavy mix of consumer transfers, high-value business payouts, international remittances, and time-critical payroll transactions flows through the payment switch.

Under heavy volume, your low-cost provider suffers severe latency and intermittent failures, while a primary alternative experiences a sudden outage. Every payment routed consumes provider capacity for multiple ticks until settlement completes. Every decision directly shapes future queue depth, available capacity, and timeout risk.

You begin with an empty rule set. Evaluate every incoming payment against live provider health before deciding its destination.

Filter out offline or ineligible providers first. Dispatch urgent payroll, time-sensitive, and high-value payments to low-latency, highly reliable routes before capacity is exhausted. For flexible, routine transactions, optimize across fees, current latency, and free capacity.

When a provider fails, avoid resubmitting to the same failing route; retry only if sufficient deadline budget remains, or hold temporarily if a healthy route will open.

What this teaches

Design a load-aware routing algorithm that balances immediate transaction requirements against future provider capacity and latency.

Evaluation contract

  • Completion and sustained throughput: 25%
  • Deadline and priority service-level protection: 30%
  • Outage, recovery, capacity, and retry correctness: 25%
  • Cost and congestion efficiency: 20%
Scroll down to build and test your solution.

Active controller

Apply & Run executes only the selected controller.

How a rule works

A rule has two parts:

WHEN <something is true> → DO <this action>

  • WHEN is a question about what is happening right now. For example: "Is it raining?" or "Is there a wall ahead?"
  • DO is what happens when the answer is yes.
  • The simulation runs one step at a time.
  • On each step, the rules are checked from top to bottom.
  • The first rule that is true wins. The rules below it are skipped for that step.
  • To change which rule wins, move it up or down the list.
  • If no rule is true, nothing happens on that step.
  • Some actions have more than one step, like "turn right, then move". You build these in the Functions tab.
  • Once a multi-step action starts, it finishes all its steps before the rules are checked again. It only stops early if the next step is not safe.
See an example

Two rules for deciding about an umbrella:

1  WHEN isRaining  → take an umbrella
2  WHEN always     → leave the umbrella at home
  • It is raining. Rule 1 is true, so you take an umbrella. Rule 2 is skipped.
  • It is sunny. Rule 1 is false, so rule 2 is checked next. Rule 2 is always true, so you leave the umbrella at home.
  • Order matters. If rule 2 were on top, it would be true every day, and you would never take an umbrella.

Rule folders

Categorise cards without changing their global execution order.

No rules yet. Nothing will happen until you add at least one rule.