One platform, four parts that answer for each other.
Ferrite is not a single service with a broad name. It is four cooperating components with a defined contract between them, so you can reason about correctness at the boundary of each.
The path an event takes
Ingest gateway
- Producer connections
- Schema validation at the boundary
- Backpressure signalling
Durable event log
- Append-only partitions
- Per-key ordering
- Replayable offsets
Stateful runtime
- Keyed operators
- Windowing and joins
- Checkpointed local state
Read surfaces
- Materialised views
- Change subscriptions
- Sink connectors
- A
Ingest gateway
- · Producer connections
- · Schema validation at the boundary
- · Backpressure signalling
- B
Durable event log
- · Append-only partitions
- · Per-key ordering
- · Replayable offsets
- C
Stateful runtime
- · Keyed operators
- · Windowing and joins
- · Checkpointed local state
- D
Read surfaces
- · Materialised views
- · Change subscriptions
- · Sink connectors
Ordered log
Queues that discard history force every consumer to be correct the first time. Recovery becomes guesswork.
Events are appended to partitioned, append-only streams. Partition assignment is by key, so all events for an account, device or order remain in sequence relative to each other.
Consumers track offsets, which means a workload can be rewound deliberately: to recover from a bug, to add a new derived view, or to test a change against real history.
Append-only partitioned log with per-key ordering.
Configured per stream, according to how far back you need to replay.
Offset-based, so multiple independent consumers progress at their own pace.
Stateful runtime
Stateless processing pushes every lookup to an external store, and the store becomes the bottleneck and the correctness risk.
Operators are keyed: the runtime routes each event to the instance that owns its key, and that instance holds the state for that key locally alongside the computation.
State is checkpointed against log offsets, so a restart resumes from a consistent point rather than re-deriving everything or double-counting.
Filter, map, enrich, aggregate, window and join over keyed streams.
Local to the operator instance, checkpointed and recoverable.
Event time and processing time handled separately, with explicit late-data policy.
Read surfaces
Derived results trapped inside a pipeline are useless to product teams; copying them into another database adds a second consistency problem.
Derived state is exposed as materialised views that reflect the stream as it advances, queryable by key or range.
Applications that need to react rather than poll can subscribe to changes on a view and receive updates in order.
Point and range reads against current derived state.
Ordered change notifications per key.
Sink connectors write results outward to downstream systems.
Control plane
Stream workloads drift. Without version and progress visibility, nobody can say which code produced which result.
Workloads are deployed as versioned units. The control plane records what is running, from which offsets, and how progress is advancing per partition.
Operational signals — lag, checkpoint status, restarts, skew across keys — are surfaced per workload rather than aggregated into a single opaque figure.
Versioned workloads with explicit start position.
Per-partition progress, checkpoint state and restart history.
Roll forward or replay from a chosen offset.
What Ferrite deliberately does not do
Scope discipline is part of the design. Where a capability belongs elsewhere, we integrate rather than reimplement.
Long-horizon analytical storage and ad-hoc historical querying stay in your analytical estate.
Ferrite serves derived state to systems and applications; presentation stays with your own tools.
Where a model is part of a decision, Ferrite delivers the features and the event context to it.
Evaluate it against your own workload.
Send us the shape of your stream — volume profile, key cardinality, ordering requirements — and we will walk through how the components would be configured.