Roadmap

StoatFlow 1.0.0-rc.1 is cut and the 1.0 feature set is frozen — between the candidate and 1.0.0 the only changes are bug fixes, and general availability follows the evidence from real workloads, not a calendar. The current release is 1.0.0-rc.1. The full account of the road here is in From first alpha to release candidate.

Items are grouped by status, not by date. Each piece ships when it's production-ready, alongside the benchmarks and changelog entry that go with it. Order within each section reflects current priority.

Shipped on the 1.0.0 line

Highlights from the twelve weeks between the first alpha and the candidate — the changelog carries the full list.

• Hot-standby high availability — an opt-in active/passive pair, grown into multi-standby clusters with lag-aware election and in-place recovery, measured scenario by scenario.
• Migration tooling — an OpenRewrite recipe that rewrites the code, a migration tool that carries a Kafka Streams application's state across the cutover, and an AI skills pack for the assistants writing against StoatFlow.
• First-class Maven builds — BOM, parent POM, and stoatflow-maven-plugin, mirroring the io.stoatflow Gradle plugin.
• Kafka Streams–compatible metrics mode — an opt-in mode publishes under the Kafka Streams metric names, so existing Grafana dashboards and alerts keep working.
• Internally consistent emission — barrier-consistent output, measured to zero.

Next — the 1.1 line

Reviewed designs leading the first minor release after GA.

• Side outputs — Flink-style multi-output processors. Emit secondary streams from a single processor step without re-keying.
• Async I/O processor — Non-blocking external lookups (HTTP, RPC, database) with bounded concurrency and ordered output, designed for enrichment workflows.
• Interactive queries over REST — Read state stores over HTTP from an opt-in module — point lookups, ranges, and windowed fetches — without writing a server.

Designed, not yet scheduled

Designs reviewed and approved; sequencing follows the 1.1 line.

• Multi-table joins — Joining a stream against multiple state stores in a single processor, replacing the current chain-of-binary-joins pattern.
• CEP pattern recognition — Detect sequences of events with a Flink-style Pattern API — a capability Kafka Streams does not have.
• Queryable hot standbys — Serve read-only interactive queries from a standby's near-live state, for read scale-out.
• Object cache for state stores — Opt-in per-store cache of deserialised objects, cutting RocksDB reads and serde cost on hot keys.
• Dispatch tiers — Source-level priority for topologies that mix live and bulk workloads. Background reloads (e.g. master-data refreshes) defer to live traffic, so a 100M-row bulk load doesn't stall live-side window closures or SLAs.
• Expanded benchmarks — Additional workload classes — windowed aggregations, foreign-key joins, async enrichment — on heterogeneous hardware.

Exploring

On the radar; design and scope still being assessed.

• Blue-green deployments — Coordinated version cutovers, building on the shipped multi-standby HA; see High availability.
• Framework integrations — First-class modules for Spring, Micronaut, and Quarkus.

Have a use case that depends on something not listed? Get in touch — roadmap priority follows real customer demand.