Events in
order.
State in reach.
Ferrite is infrastructure for data in motion. A durable ordered log, a stateful stream runtime and read surfaces engineering teams can reason about — so an event can change what a system knows the moment it arrives.
Per-key sequence preserved end to end
State rebuilt by replaying the log
Behaviour you can inspect while it runs
Most data platforms were designed to answer questions about the past.
Warehouses and batch pipelines are excellent at describing what already happened. They are a poor fit when a decision has to be made while the event is still relevant — a payment being authorised, a device reporting a fault, an account changing state.
Teams usually close that gap with bespoke queues, caches and cron jobs. It works until ordering, retries and partial failure start producing results nobody can explain.
Ferrite treats the ordered event stream as the primary source of truth, and makes the state derived from it a first-class, queryable part of the system.
Four stages, one continuous path
Data enters once, keeps its order, updates state as it passes, and leaves through surfaces built for reading. Each stage is separately observable and separately scalable.
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
What you actually run
An append-only, partitioned event log. Producers append; consumers read by offset; history stays replayable so state can always be rebuilt from source.
Keyed operators that filter, enrich, join and window events while holding local state next to the computation, checkpointed for recovery.
Materialised views and change subscriptions, so applications can query current derived state or follow it as it changes.
Deployment, versioning and observability for stream workloads: what is running, on which code, consuming from where.
Where an ordered stream changes the design
- 01Operational decisioningEvaluate rules and models against a live event stream instead of yesterday's table.
- 02System of record synchronisationPropagate committed changes between services without nightly reconciliation jobs.
- 03Telemetry and device streamsAggregate high-cardinality signals per key and keep the aggregate queryable.
- 04Continuous auditabilityRetain the ordered history that produced a result, so it can be replayed and inspected.
Built to be run, not just demonstrated
Streaming systems fail in ways batch systems do not: skew, late data, hot keys, poison records. The platform is designed so those conditions are visible and recoverable rather than silent.
Reprocess from a chosen offset to rebuild derived state.
Workloads are versioned and deployed independently.
Slow downstream stages signal upstream instead of dropping work.
Per-operator and per-partition progress is exposed.
Bring us your data flow, not a form.
Tell us where events originate, what has to happen to them and what currently breaks. We will respond with an architecture-level answer.