How SQL‑Based Rule Configuration Cuts Release Cycles from Days to Minutes

Pain Points: Every Rule Change Requires a Release

In traditional code‑based validation systems, even simple rules like order_amount = product_amount - discount_amount must pass through requirement, review, development, testing, release, and deployment, taking 2–3 days. High‑frequency rule changes make this process inefficient.

Slow response : 2–3 days to activate a rule.

High cost : Each rule iteration needs roughly 2 person‑days of development and 1 person‑day of release.

High risk : Code changes can introduce bugs and require emergency rollbacks.

Making SQL the Rule

The core insight is that validation rules are essentially data queries + conditional checks , which map naturally to SQL. By configuring a rule as a SQL statement, the workflow changes from "write code → release" to "configure SQL → publish" and reduces delivery time by over 95%.

Business requirement → configure SQL → debug → publish (≈30 minutes).

Architecture and Core Technologies

The system is built around plug‑in event triggers, configurable SQL rules, memory‑level isolation, and intelligent parallel execution.

Event triggers support dynamic registration of data sources (Kafka, MySQL) and precise rule activation.

SQL rules are defined with placeholders (e.g., ${field}) that are automatically injected at runtime.

Online debugging validates SQL correctness, performance, and safety before deployment.

SQL parsing and lineage analysis use a customized JSqlParser engine to extract table dependencies, fields, conditions, and parameters, generating a lineage graph.

SELECT
  o.order_no,
  o.order_amount,
  p.payment_amount
FROM order o
LEFT JOIN payment p ON o.order_no = p.order_no
WHERE o.order_no = '${order_no}'
  AND ABS(o.order_amount - p.payment_amount) > 0.01;

The engine identifies required tables and parameters, enabling automatic data preparation.

Data‑fingerprint grouping shares query results among rules with identical data requirements, reducing duplicate I/O and allowing parallel execution within each group.

Memory‑snapshot isolation uses a pooled MariaDB in‑memory instance to load all required data, execute the SQL rules, and then release the instance, ensuring no impact on production databases.

Key benefits: reduced duplicate queries, parallel group execution, and safe, isolated computation.

Results and Practice Summary

Configuration efficiency : rule rollout time shrank from days to minutes, improving delivery speed by >95%.

Cost savings : eliminated development, testing, and release steps.

Data reuse : rules sharing the same data fingerprint reuse query results, so more rules lead to higher efficiency and lower marginal cost.

Outlook

Future enhancements include a visual drag‑and‑drop configuration UI, AI‑assisted rule generation from natural language, and real‑time monitoring dashboards to further lower the barrier for rule creation and improve operational safety.