Skip to content

PATTERN Cited by 1 source

Routing rules as config

Definition

Routing rules as config is the pattern of expressing load-balancer / gateway routing decisions as human-readable, individually-named, individually-editable rules in configuration (or a rules store) rather than as hard-coded logic in the gateway binary. Each rule has a name, a description, a condition, and actions; rules are evaluated per request against inspectable request properties (parsed protocol fields, headers, identity).

Canonical shape (Trino Gateway)

From sources/2026-03-24-expedia-operating-trino-at-scale-with-trino-gateway:

name: "large-table-query"
description: "Route queries for large tables"
condition: "true"
actions:
  - |
    foreach (table : trinoQueryProperties.getTables()) {
      String tableSuffix = table.getSuffix();
      if (tableSuffix.contains("table1") || tableSuffix.contains("table2")) {
        result.put("routingGroup", "large-cluster");
        return;
      }
    }

Four ingredients:

  1. name — identity for UI display, logs, and rule edits.
  2. description — human-readable intent.
  3. condition — boolean short-circuit: if false, skip the rule entirely; if "true", always evaluate the actions.
  4. actions — body that inspects the request and writes outputs (typically: a routingGroup name into a result map the gateway reads).

Inspectable surfaces

A query-gateway rule engine typically exposes:

  • Parsed protocol properties (trinoQueryProperties.getTables(), .getBody()) — what is the client asking for.
  • Raw request properties (request.getHeader(...), request path) — who / what is the client.
  • Identity / auth context — caller principal, team, tenant.
  • Mutable output map (e.g. result.put("routingGroup", "…")).

Why rules-as-config instead of code

  1. Hot-editable. Rules change faster than gateway releases. A rule edit should not require a redeploy.
  2. Human-readable. Rules codify operational policy; non-engineer reviewers (platform leads, compliance, SREs) need to be able to read the rule set.
  3. Auditable. Rules are the operational contract; they should be versionable, diff-able, and reviewable like any other config-as-code artifact.
  4. Individually addressable. Named rules let operators disable / modify one rule without touching the others.
  5. UI-exposable. A rules DSL is a natural target for a GUI rule editor (Expedia's PR #433 for Trino Gateway is the canonical example — "administrators can now easily view existing rules, modify them as needed, and save the changes").

Before Expedia's contribution

Before the UI for rule management landed, rule inspection required reading configuration files or examining the gateway environment; rule edits were file edits. The post calls this out as "cumbersome," "prone to errors," and requiring technical expertise disproportionate to the task. The structural fix was a persistent rule store + UI so rules become a first-class runtime artifact rather than a config-file asset.

Why not declarative (match/route tables)?

Pure declarative routing (e.g. ingress-level host == "api.foo.com" → backend-a) is enough for static shape matching, but falls short when:

  • The routing decision has to parse application payload (here: a SQL query's table list).
  • The rule has to walk a collection and apply logic per-element (e.g. foreach table).
  • Rules accrete dozens of small cases whose boolean combination would produce a combinatorial explosion in a purely declarative grammar.

A small scripting surface per rule (what Trino Gateway uses — Groovy-like) is a pragmatic middle ground: simple rules stay declarative-looking; complex rules can do table iteration and conditional logic without leaving the rule surface.

  • concepts/json-serializable-dsl — Figma's permissions DSL; overlapping "config is executable" discipline on the authz-policy side.
  • Open Policy Agent / Rego — similar pattern applied to authorisation decisions across the stack.
  • Envoy xDS config — declarative routes + match trees; less flexible than scripted rules but with better static-analysis properties.

Trade-offs

  • Rule-set drift. Over time, rules accrete. UI + naming discipline + tests are the counterpressure.
  • Rule evaluation latency. Every request pays for rule evaluation. Short-circuiting on condition is load-bearing.
  • Testability. Scripted rules are harder to unit-test than pure declarative rules; a test suite with sample requests is usually needed.

Seen in

Last updated · 200 distilled / 1,178 read