Kafka, Pulsar and MQTT move events at enormous scale, but moving an event is not the same as deciding on it. The moment a decision needs trusted context, such as an account balance, a live session, a device status or an inventory level, the event leaves the stream for a round trip to a cache, a database or a hand-written client application. Every hop adds latency, another component to operate and another place to fail. That is how fraud slips through, offers miss their window, enforcement lags and cloud costs climb. Bolting more infrastructure onto the stream only moves the problem somewhere else.
What VoltSP changes in the pipeline
VoltSP stream processing closes that gap by putting the decision inside the pipeline. The breakdown below shows how VoltSP reads events from Kafka, Pulsar, MQTT, HTTP, S3 and files, calls VoltDB for the live state a decision depends on, and pushes the result downstream in milliseconds. You’ll see how it compares with a typical stream processor on stateful decisions, consistency, windowing, deployment, machine learning and failure handling. You’ll also see where it removes the caches and glue code that usually sit between the broker and the data platform.
How a VoltSP pipeline works
Every VoltSP pipeline is a source, one or more processors and a sink, defined in a visual workflow editor, in YAML or in Java. Stateless work such as filtering, transforming, aggregating over time windows and running machine learning models saved in ONNX, an open model format, happens in the pipeline itself. Stateful decisions happen in VoltDB, where a single stored procedure reads the context, applies the logic and records the outcome in one ACID transaction, so the whole step succeeds or fails as a unit. VoltSP commits each batch only after every downstream operation succeeds, and circuit breakers, which pause traffic to a struggling system, hold the pipeline back instead of letting it overwhelm that system. Pipelines run as self-contained pods on Kubernetes or on bare metal, and each one scales independently of the broker and the Volt cluster.
Who it’s for
For platform engineers, data architects and teams running charging, policy or fraud systems, the shift is from a data pipeline that hands events to something else for a decision to a decision pipeline that acts on each event while it still matters. Less data reaches downstream storage, and fewer services sit in the request path. Every decision runs against current state rather than a stale copy. If you’ve already tallied what a multi-hop streaming stack costs, the Kafka tax breakdown is a useful companion. Read on to see how VoltSP fits between your broker and the systems that act on its events.