How a Visual Canvas Transforms High‑Performance Marketing Workflow Engineering

Introduction

Current marketing activities rely on the Apollo configuration system, which provides filter and trigger components but lacks workflow branching, component governance, and visual representation, leading to low cohesion, high coupling, and error‑prone manual configuration.

Technical Selection

Front‑end: several open‑source graph/flow libraries were evaluated (AntV XFlow, React Flow, Dagre, jsPlumb, Ant Design Graph). XFlow was chosen for its out‑of‑box flow diagram, Ant Design integration, and comprehensive documentation.

Back‑end: mainstream Java workflow engines (BPMN 2.0, LiteFlow, Gobrs‑Async) were surveyed, but none met the lightweight, high‑performance requirements, so a custom engine based on Spring Reactor was built.

Comparison with n8n highlighted that n8n targets technical users, while the canvas must be usable by product and operations staff without coding.

System Design

The canvas represents a directed acyclic graph (DAG). A configuration service stores canvas metadata, versioning and publishing; an execution engine parses the DAG, coordinates component execution, and manages shared context data.

Interaction diagram and execution engine architecture are shown below.

Component Ecosystem

Components are grouped by function:

Behavior strategy : in‑app user actions, MQ messages, business direct calls, tagger real‑time tags.

Logical branching : IF, selector, logical relation (AND/OR).

Audience selection : tagger offline tags, AB split.

Reward issuance : voucher distribution.

User reach : in‑app notification, reach platform, direct return.

Auxiliary : API call, delay, MQ send, priority, Groovy script, hub.

Innovations

Multi‑stage execution enables complex scenarios where several behavior strategies must be satisfied before the whole flow proceeds. Sub‑process nesting provides reusable workflow modules, and table‑based configuration offers a matrix view for multi‑dimensional strategy factors and data attributes.

Technical Challenges & Implementation

Concurrency lock : implemented a lock‑free local lock using AtomicBoolean and a distributed lock via Redis SETNX with a 15 s expiry and heartbeat, avoiding thread‑bound locks in Reactor.

Concurrent processing : hub and logical‑relation nodes may be triggered many times; a “retry‑once” strategy ensures the final execution succeeds without excessive locking.

boolean lock = result.getWaitProcess().compareAndSet(true, false);
if (!lock) {
    result.getWaitProcess().set(true);
    return Mono.empty();
}
do {
    // processing logic
} while (isRepeat(result));

private boolean isRepeat(Result result) {
    if (result.status == 'success') {
        return false;
    }
    boolean repeat = result.getWaitProcess().get();
    result.getWaitProcess().set(false);
    return repeat;
}

Deployment Results

After launch, configuration time dropped from one day to one hour (≈90 % improvement). The system now supports over 100 stable marketing activities, adds more than 3 000 daily new orders, achieves 99.95 % availability, and keeps core API latency below 50 ms.