How to Build a Scalable Marketing Automation Engine with FSM and Real‑Time Controls

Introduction

As business needs grow, product and operations teams demand more sophisticated marketing tools. Simple utilities like coupon distribution or message sending become inefficient for complex, multi‑step campaigns. A marketing automation system addresses this by allowing visual "canvas" design, execution monitoring, funnel analysis, and interval analysis.

Requirement Analysis

1. Essence of Marketing – Merchants aim to increase revenue by interacting with users through defined marketing rules.

2. Common Marketing Pattern

Merchants define rules and notify users via channels.

Users engage (share, enter draws, use coupons).

When rules are satisfied, rewards (coupons, physical goods, discounts) are issued.

3. Operational Pain Points – Low user participation or unused coupons force operators to re‑select target users offline and repeat the cycle.

Desired System Capabilities

Support user‑customized marketing plans.

Automatically execute complex, multi‑step, branching workflows.

Proactively trigger users.

Monitor user behavior.

Provide risk‑control such as participation frequency.

Architecture Design

The system is organized into four layers, analogous to a JVM development stack:

Marketing Automation Application – An IDE‑like interface where users draw their marketing ideas.

Marketing Automation API – Defines integration contracts similar to Java/Scala APIs.

Marketing Automation Translator – Binds the API and translates it into a bytecode‑like format the engine can understand.

Marketing Automation Engine – Executes the bytecode according to a defined model.

Engine Model: From Graph to Action

The engine is built on a Finite State Machine (FSM) model driven by trigger conditions.

Graph (campaign) defines audience, schedule, participation limits, and preset user paths.

Each user follows a single path per participation; branching decisions depend on user behavior.

Paths can be parallel (multiple active paths up to the frequency limit) or serial (only one active path at a time).

Side (trigger) represents conditions, which may combine events with logical AND/OR, originate from system monitors (timers, delays, location), or be direct user actions (purchase amount, keyword search, button click).

Point (marketing action) is the set of actions executed once a trigger fires, such as push notifications, coupon issuance, prize distribution, discounts, or resource grants. Execution order supports three strategies:

Parallel – actions run simultaneously.

Serial – actions run sequentially, each dependent on the previous success.

Priority – higher‑priority actions run first; if they succeed, lower‑priority actions are skipped.

Engine Modules

State Control – Core FSM implementation managing user campaign states.

Time Control – Minute‑level scheduling via Redis, arbitrary timing via crontab, and step‑based delay handling.

Event Rule Control – Monitors user events, validates them against configurable rules, and forwards qualified events to the state controller.

Action Execution Control – Executes marketing actions (e.g., SMS, coupons) after state transitions.

Monitoring Center – Provides alerts for each engine component.

Exception Handling – Custom retry system with automated recovery and manual intervention for unresolved failures.

Data Warehouse – Stores trigger data, action data, and user campaign state flows, enabling funnel and interval analysis as well as integration with other business data.

Technical Details

The rule engine supports two‑dimensional array expressions for complex logical combinations.

(productId == 1 || productId == 1) && (cityId == 2) && (price >= 20) -> [[productId eq 1, productId eq 1],[cityId eq 2],[price lte 20]];

It also supports multi‑event AND/OR logic using Redis‑backed 2‑D arrays, e.g.:

(total spend ≥ 20 CNY or 5 orders) and (post count ≥ 10) -> [[total spend ≥ 20, 5 orders],[post count ≥ 10]]

Conclusion and Outlook

The marketing automation system transforms complex campaign logic into an automated, observable workflow, improving operational efficiency and providing rich data for post‑campaign analysis. Future articles will dive deeper into each technical component, such as high‑throughput input handling, QPS limits for downstream systems, timeout recovery, and advanced Redis‑based rule evaluation.