Cookies and Privacy

We use technology on our website to collect information that helps us enhance your experience and understand what information is most useful to visitors.
By clicking "I ACCEPT," you agree to the terms of our privacy policy.

Cirata applies the highest standards to its use of data and its compliance with data-protection regulations across our marketing and website. Our Data Protection Officer can be contacted at DPO@cirata.com. You can change your cookie settings at any time via the link in our footer.

Cookie Setting

Canon extension

Canon extension

Replicate Kafka across any vendor mix, with offsets every instance agrees on, schemas that travel with records, and failover you can actually rehearse.

Built by Cirata | Tech Preview

Replicates across the Kafka estate you actually have

Canon doesn't pick sides. Standard Kafka clients on either end mean any vendor that speaks the protocol is a valid source, a valid target, or both, including bidirectional active-active and N-cluster mesh topologies with target-aware loop prevention built in.


Sources & targets:
Apache Kafka · Confluent Cloud & Platform · Amazon MSK · Redpanda · WarpStream · Red Hat AMQ Streams · IBM Event Streams · any Kafka-protocol broker


Replicates:
Records (with offset-pair agreement) · consumer-group offsets · schemas (Confluent-compatible Schema Registry) · topic configs · ACLs (with delete propagation)

Replicates across the Kafka estate you actually have

What it does

  • Replicate Kafka across vendors, Apache, Confluent, MSK, Redpanda, WarpStream, with the same extension and ordinary clients.
  • Agree every (source, target) offset pair across every Canon instance before the source commit lands, so failover translation gives the same answer from every control-plane path.
  • Carry schemas with records, auto-push to the target registry and rewrite Confluent wire-format IDs in flight, one switch per link.
  • Replicate ACLs with snapshot-replace semantics, so revoked permissions actually disappear on the target.
  • Fail over with a per-direction ceremony you can drain, complete, restore, and rehearse in drills before the disaster.
What it does screenshot 1
What it does screenshot 2

Use cases

Cross-vendor disaster recovery

Fail over from Confluent to MSK, from Apache to Redpanda, or between regions of either, with a rehearsable per-direction ceremony, fabric-agreed offset translation, and an audited activity log a regulator can actually read.

Kafka migration without lock-in

Move from one Kafka vendor to another at your pace. Run both sides live, replicate either direction, cut consumers over when the offsets, schemas, and ACLs all match, no Connect cluster, no operator-built audit story.

Active-active across vendors

Run bidirectional links with target-aware loop prevention, so a record that's already visited a cluster doesn't visit it again. N-cluster mesh is a first-class topology, not a sharp edge.

Regulated-industry evidence

Answer the auditor's question, can you evidence cross-vendor failover, schema lineage, and ACL governance? With a verifiable trail of every replication decision. Built for DORA, Basel III, NYDFS Part 500, and APRA CPS 230.


How it works

Link

Define a link between any two Kafka clusters in the Symphony UI. Standard Kafka credentials on each side; Canon handles the rest.

Agree

Every Canon instance agrees each (source, target) offset pair, schema mapping, and ACL snapshot through a consensus-backed fabric before the source commit lands.

Operate

Drain, fail over, restore, and rehearse from the UI, REST, CLI, or any MCP-speaking agent. The same contract drives every operation.


Technical details

Replication model Standard Kafka clients on both ends, idempotent producer (optional transactional path); source offset committed only after fabric agreement.
Consensus DConE (Multi-Paxos), in-process; one replicated state machine per logical link; per-direction failover state keyed on (linkId, direction).
Topologies Unidirectional, bidirectional active-active, and N-cluster mesh — with target-aware loop prevention via the canon.origin-chain header.
Replicates Records, consumer-group offsets (timestamp-anchored), schemas (Confluent wire-format ID rewriting), topic configs, ACLs (snapshot-replace with delete propagation).
Sources & targets Any Kafka-protocol broker, Apache Kafka, Confluent Cloud & Platform, Amazon MSK, Redpanda, WarpStream, AMQ Streams / IBM Event Streams.
Operator surface UI, REST, CLI, and MCP over one OpenAPI contract (20 operations); 16 pages of in-app help; observability counters, gauges, and traces propagated across Kafka and messaging.

Other Cirata Symphony extensions

Cirata Symphony Pulse extension
Control, understand, coordinate, and automate your data estate using simple prompts.
Data Migrator extension
Fully automated, zero-downtime or risk, continuous petabyte scale data migration between data environments.
Observability extension
See your entire Cirata Symphony estate as one OpenTelemetry stream, every extension, every signal, into any backend you already run.
Intelligence extension
Connect your data estate to any AI model, without writing a line of integration code.
Orchestration extension
A vendor-neutral control plane for workflow orchestration on Cirata Symphony. Orchestration connects to the workflow engines you already run, behind one unified Orchestrator interface.
Ice Flow extension
Manage data in Iceberg-native, open standard formats, between any pair of catalogs, across vendors, clouds, and on-premises, without compromise or lock-in.

Want to see the Cirata Symphony Canon extension in action?

Let us show you how the Cirata Symphony Canon extension is a revolutionary new data extension to fit your organizational needs.
Schedule a direct 1:1 demo with our CTO, Paul Scott-Murphy.