Event streams with
no broker in between.
Changes from the systems you already run travel peer-to-peer, signed and in order. It works like Kafka, inside and between organisations, with privacy built in.
Trusted by government and industry
Event streaming stops where the data gets sensitive.
Events may already flow in real time, often over Kafka. As soon as another department with its own mandate, a supplier or a regulator needs them, sharing turns into exports, API polling and nightly batches.
The same event stream can reach them, with each field encrypted for whoever is entitled to it and no broker or central party you have to trust.
Today
- Real time inside one team's systems, batches across every boundary
- A custom integration for every department and partner
- No shared event log across boundaries
- Compliance events arrive days after they happen
Privacy-preserving event streaming
- Real-time publish and subscribe across every boundary
- A connector next to the databases you already run
- Cryptographic event ordering and verification
- Regulators receive compliance events in order, when they occur
Streaming between departments and organisations.
The publish and subscribe model you know from Kafka, with privacy-enhancing technologies built in and no central broker that can read the events.
01
Across every boundary
Publish and subscribe reaches beyond your own team and your own organisation. Each party receives the changes it is entitled to as they happen, without polling an API or waiting for a batch.
02
In a provable order
Every event is signed and placed in one shared order, so every party can prove which change came first.
03
Checked on arrival
The receiving connector checks each event's signature and mandate before applying it. An event without a valid mandate does not count.
04
Catch up and replay
A party that was offline catches up from the ordered stream, so what it holds agrees with the others again. Replaying the stream shows how each result came about.
How an event travels
One event, end to end.
How one change travels from the system where it starts to every organisation entitled to it.
- 01
Published at the source
A record changes in the system where it starts, for example a supplier books an invoice. The connector next to that system turns the change into an event and signs it.
- 02
Delivered peer-to-peer
The event travels peer-to-peer to the organisations subscribed to it. Each field is encrypted for the parties entitled to it, so whoever delivers the event cannot open it.
- 03
Placed in order
The event gets its place in one shared order, with a timestamp and a proof on a public, append-only log, so every party agrees on what happened first.
- 04
Checked and applied
Each receiving connector checks the signature and the mandate, then applies the event to its own data store. What the parties share agrees, and the exchange is in the audit trail.
How it compares with batch and Kafka
When changes arrive
- Batch processing:
- At the next batch run
- Kafka inside one organisation:
- As they happen, inside the organisation
- mintBlue event streams:
- As they happen, inside and between organisations
Sharing with other organisations
- Batch processing:
- File transfers
- Kafka inside one organisation:
- API polling or exports
- mintBlue event streams:
- Publish and subscribe across organisations
What sits in the middle
- Batch processing:
- A file server or transfer service
- Kafka inside one organisation:
- Your own brokers
- mintBlue event streams:
- No operator who can read or reorder; peer-to-peer between organisations
Event ordering proof
- Batch processing:
- No ordering guarantee
- Kafka inside one organisation:
- Within a partition
- mintBlue event streams:
- One provable order across organisations
Audit trail
- Batch processing:
- Logs that can be altered
- Kafka inside one organisation:
- Limited by retention
- mintBlue event streams:
- Tamper-evident history every party can check
Connecting your systems
- Batch processing:
- Custom scripts per system
- Kafka inside one organisation:
- Connectors you build and run
- mintBlue event streams:
- A connector next to the databases you already run
Frequently asked questions
Architecture
Integration
Next step
Stream one exchange first.
Name the changes another department or organisation needs from your systems, and we sketch the connector and the event stream with your architects.
Next step
Stream one exchange first.
Name the changes another department or organisation needs from your systems, and we sketch the connector and the event stream with your architects.