Fluxtion + Mongoose

Fluxtion is the logical layer. You author event-driven logic in Java; inferred orchestration compiles it to a single, portable .class with audit and replay-equivalence built in.

Mongoose is the physical layer. Same compiled class — threading, transport, persistence, and time sources around it are plugged in by configuration. The processor doesn't change when you move from your laptop to production; the deployment descriptor does. Mongoose, Flink, Kafka, Chronicle and Aeron are wires and hosts; Fluxtion is the deterministic logic the wires carry.

One compile. Three runtimes consume the same .class. Mongoose is the production-grade container; the playground and any embedded JVM consume the identical artifact.

Deployment is plugin selection, not a code change

The processor compiles once. Moving from playground to Mongoose swaps the feeds, the sinks, the idle strategy, and the persistence story — all in the Mongoose deployment descriptor. Your graph, your nodes, your generated Processor.java do not change.

What changes, what stays the same

Concern	Playground	Mongoose (production)
Generated processor	Identical · same `.java` + `.class` + `.graphml`
Event types & nodes	Identical · your authored Java doesn't change
Replay determinism	Identical · same input ordering ⇒ byte-equal sink output
Audit surface	Identical · same per-event records, same hook points
Feeds (event sources)	`InMemoryEventFeed`, file feed via DSL connector	aeron-feed · chronicle-queue-feed · kafka-feed · file-feed · admin gates · scheduled timers
Sinks	in-process callbacks · `FileMessageSink`	kafka-sink · postgres-append · chronicle-queue-sink · custom plugins
Threading	single-threaded · `SleepingMillisIdleStrategy(1)`	agent threads · `BusySpinIdleStrategy` / `YieldingIdleStrategy`
Persistence	`HashMap` in JVM	snapshot plugin · checkpoint replay · cold-start from log
Audit destination	stdout `[FLUXTION_AUDIT]` blocks	OpenTelemetry · Splunk · regulator trail · multi-auditor
HA / scale	single JVM	hot-warm pair (replay-determinism is the failover correctness contract) · sharding by key

Fluxtion · logical layer

Graph analysis at compile time — every node, every trigger, every audit point known statically
Output is plain Java — your auditor reads it, your IDE navigates it, your VCS diffs it
Runtime dependency is just fluxtion-runtime — no compiler, no codegen at startup
Deterministic dispatch order, replay-equivalence, structural audit — all by construction

Mongoose · physical layer

Agent-thread runtime container — hosts your processor inside an AgentRunner group
Feed + sink plugins — file, aeron, chronicle, kafka, multicast, custom
Service plugins — admin (REST / telnet), JDBC, cache, scheduler, YAML / Spring loader
Lifecycle, idle strategies, snapshots, multi-processor groups — all configured, not coded

What this means in practice

Author and iterate in the playground. The processor compiles, the JUnit tests run, you see the audit and the replay. When you're ready for production, the same generated Processor.class ships in your release jar; Mongoose's deployment descriptor wires it to your real feeds, sinks, and services. There is no “production rewrite” step — there isn't one to do.

The same property carries the other direction too: when a production incident reproduces oddly, pull the event log, replay it against the same processor in the playground, watch the audit unfold. The replay path is the debugger.

Worked examples

Fluxtion examples

telaminai/fluxtion-examples

Author-side examples — DSL, imperative, Spring XML, vendor JARs, every authoring channel covered. Output is the portable .class.

Mongoose examples

telaminai/mongoose-examples

Runtime-side examples — how to wire processors into Mongoose, configure feeds and sinks, register services, run the admin plane.

Open the playground Read the Mongoose docs

See also: Code-gen at a glance — the authoring channels × generation modes matrix that feeds into the compile box above.