A 98KB Workflow Engine Makes Sense When You Only Need Approvals, Not a BPM Platform

Why Write a Lightweight Workflow Engine in the Flowable Era

jeeflow Series · Part 1 (Getting to Know the Season)

Almost every week, someone in the backend group asks the same question: "What should I use for approval flows?"

The answer is always the same: Flowable.

But few people ask the follow-up question—once the technology selection is done, the story is just beginning: when an engine with jars weighing several MB, a pile of dependencies, and dozens of tables enters your business system, is it "introducing a capability" or "introducing a headache"?

This article doesn't try to dissuade you from Flowable, nor does it promote building your own. We'll do the math: what exactly makes mature engines like Flowable, Activiti, and Camunda so expensive? In what scenarios is a 98KB lightweight engine the more rational choice?

This series is a continuation of the mldong rapid development framework ecosystem. Part 0, "From mldong to jeeflow: The Independent Evolution of a Workflow Engine," covered the complete backstory of jeeflow. Feel free to read that one first.

1. Where the Costs of Mature Engines Hide

Flowable, Activiti, and Camunda are all excellent implementations of the BPMN 2.0 standard, and their power is undeniable. But "powerful" comes with a price tag, and that bill usually gets paid gradually after going live:

1. The engine itself is not light. The Flowable engine jar is several MB. Add modules for process definition parsing, forms, history, and more, and the memory footprint and startup time are not trivial. If you're using the Camunda platform edition, it's an entire suite.

2. Dozens of data tables from the start. Flowable alone has 70+ engine tables (prefixed with ACT_), Activiti has around 60, and Camunda has about 30. Your database schema suddenly gains a patch of "someone else's tables," and migration, backup, and monitoring all have to adapt accordingly.

3. The learning curve isn't "steep"—it's "long." BPMN 2.0 is a complete specification in itself: swimlanes, sub-processes, events, gateways, boundary events... A new team member spends a month chewing through BPMN documentation before they can draw their first "leave request process."

4. Deep integration is your job. User systems need mapping, permissions need connecting, transactions need coordinating, and the frontend process designer needs integrating. The engine belongs to someone else; the glue code belongs to you.

5. Upgrades are psychological scars. A major version upgrade means API changes, table structure migrations, and historical data compatibility—many teams simply adopt a policy of "never upgrade the engine version."

None of this is Flowable's fault—it was simply born for a much grander goal (a complex BPM platform). The problem is: if your requirement is just "a block of approval capability within a business system," using it is like delivering takeout with a rocket.

2. So When Should You Build Your Own?

Let's state the conclusion upfront: building your own isn't about saving effort; it's about switching to a different cost structure.

Scenarios suited for mature engines:

You are building the process platform itself (targeting multi-tenancy, complex orchestration, a process marketplace)
Business processes heavily depend on advanced BPMN features (events, gateways, complex compensation)
The team has dedicated BPM engineers and can afford this complexity

Scenarios suited for lightweight self-built engines (our judgment):

The approval flow is one module within a business system, not the entire product
Process patterns are relatively fixed: initiate, approve, reject, jump, countersign, carbon copy, delegate
You want the engine to be deeply integrated with your own framework (transactions, permissions, user system, frontend designer)
You want the engine's behavior to be fully controllable, so problems can be located quickly
Business teams with multi-language tech stacks may need to connect in the future (Java / Go / Python / Node)

The cost of building your own must also be stated clearly: you must guard the feature boundary yourself (no complex BPM means no complex BPM), you must build the testing system yourself, and you bear the maintenance responsibility yourself. A self-built engine is not "free"; it shifts the cost from "learning someone else's complexity" to "maintaining your own complexity." It's only worth it when the latter complexity is significantly lower than the former.

3. A Selection Comparison at a Glance

Dimension	Flowable	Activiti	Camunda	jeeflow
Positioning	BPM Engine	BPM Engine	Process Platform	Embedded Approval Engine for Business Systems
Engine Size	Several MB	Several MB	Platform-level	98KB
Data Tables	70+	~60	~30	8 (5 core + 3 management)
Process Standard	BPMN 2.0	BPMN 2.0	BPMN 2.0	LogicFlow JSON
Framework Dependency	Requires Spring integration, etc.	Same as left	Platform-bound	Zero dependencies (only slf4j-api, provided)
Learning Curve	Steep (BPMN spec)	Steep	Steep	Flat (JSON + nodes/edges)
Extension Method	Handler / Listener	Same as left	Platform extension points	SPI system (6 core + 5 extension, any link replaceable)
Language Coverage	Primarily Java	Java	Java	Java / Go / Python / Node (4 languages)
Transaction/Permission Integration	DIY	DIY	Platform-provided	Engine-agnostic, wrapped by business-layer transaction template

Note: Table counts are approximate scales for common versions of each engine (Flowable 6.x ACT_ series has about 70+ tables), provided for order-of-magnitude reference; exact numbers should be confirmed against each engine's official documentation. jeeflow data aligns with v1.8.4 (8 tables = 5 core + design/history/delegation 3 management).

4. Our Choice: Self-Built in the mldong Scenario

The mldong rapid development framework (an open-source Java rapid development framework on Gitee) has a self-built workflow engine built in. When we made this decision, we followed the judgment above:

Clear requirement boundary: The framework needed "approval capability within a business system," not a process platform—initiate, approve, reject, jump, countersign, carbon copy, delegate: sufficient and easy to use;
Process definition uses LogicFlow JSON: Nodes + edges + expressions. The visual designer outputs this JSON when you finish drawing, with no BPMN specification burden;
Deeply integrated with the framework: Interface contracts (code=0/msg, submitType enum), user system, frontend vben5 process designer, all aligned;
The wf modules of the Java dual mainlines (boot2 / boot3) are completely identical, and the frontend works out of the box.

The engine ran well within the framework. But later we realized this capability deserved to stand alone—and so jeeflow was born: a 98KB, zero-framework-dependency, DDD-designed, SPI-pluggable workflow engine SDK, which evolved into a "multi-language federation" with isomorphic implementations in Java, Go, Python, and Node. That's the story told in Part 0.

5. Conclusion: No Silver Bullet in Technology Selection, Only Fit

Flowable is excellent, but it was born for "complex BPM." If your system only needs "approval," first calculate whether those dozens of tables, several MB of dependencies, and the BPMN learning cost are really what you want. A lightweight self-built engine is also no silver bullet—it just moves the complexity to a different place—what you gain in return is controllability, portability, and mastery.

Next article preview: "jeeflow: What Does a 98KB Workflow Engine Look Like"—the core design of a zero-dependency engine: DDD aggregate roots, 6 SPIs, state machine, 9 process patterns, dissected for you to see.