Eight concepts. Then it is just data flow.
The model is deliberately small. If you understand keys and state ownership, the rest of the system follows from those two ideas.
The model, in the words we use for it
- A named, partitioned sequence of events with a declared schema.
- The field that determines partition assignment, ordering scope and state ownership.
- A unit of processing bound to a key, holding the state for the keys it owns.
- Values retained per key between events, checkpointed against log offsets.
- A bounded grouping over event time, with an explicit policy for late arrivals.
- The queryable projection of operator state, readable by key or range.
- An ordered feed of changes to a view for consumers that react rather than poll.
- A deployed, versioned graph of operators with a defined start position.
How building on it feels
A workload is defined as a graph: where it reads, what it computes per key, what state it keeps, and what it exposes. Deployment then becomes a versioning question rather than a migration.
Declare the input streams and their keys, then the operators that transform them. Schema is declared at the boundary so malformed events fail at ingest, not in the middle of a pipeline.
Because the log retains input, a new workload version can be run over past events before it takes production traffic.
Ship the workload as a version with an explicit start offset — from now, from a timestamp, or from the beginning.
Follow per-partition progress, checkpoint state and state size per operator while it runs.
Add a new derived view without disturbing existing consumers; it builds itself from the same log.
What an evaluation involves
- 01
Scope
One real flow, chosen because it is currently painful.
- 02
Design
Keys, ordering requirement, state size and read pattern agreed in writing.
- 03
Run
The workload is built and run against representative data in your environment.
- 04
Assess
You measure the result on your own infrastructure — we do not ask you to accept ours.
Bring a real stream to the first conversation.
Volume profile, key cardinality, ordering requirement and read pattern are enough for us to be specific.