Continuity in Quazar: keeping a FIX fault contained to the hub where it happens
Continuity, in Quazar's FIX fabric, is what keeps a single fault, a bad rule, a dropped session, a hub going down, from spreading beyond where it happened. Each hub is self-contained, with its own isolated storage and configuration, so no hub is a shared point of failure for the others it connects to over FIX. Configuration and rules are stored as live, reloadable objects, which makes rollback to the last known-good configuration possible. Automated failover between hubs, moving traffic from a failed hub to a healthy one without an operator stepping in, is on Quazar's roadmap, not something it ships today.
What should be included in an RFP for FIX connectivity?
An RFP for FIX connectivity should ask how a vendor contains a fault, not only how fast it moves messages. Five questions belong on that list for any platform being evaluated.
- Fault containment. When one hub fails, does the fault stay local, or can it reach every other counterparty session on the platform?
- Configuration rollback. Can a bad routing or transformation rule be reverted to the last known-good configuration without a restart?
- Session recovery. Where is session state kept, and can a dropped session be replayed instead of rebuilt from the counterparty's side?
- Live configuration changes. Can a dictionary or mapping change go live without restarting a session carrying other traffic?
- Shipped versus planned. Which resilience features are available today, and which are on the roadmap? Ask for that distinction in writing.
On Quazar, the answers are published rather than promised. Hubs are self-contained with isolated storage, so a fault stays where it happens, with no shared single point of failure between hubs. Configuration and rules are stored and reloadable, with rollback to the last known-good configuration. Session state and message replay are covered on the session management page, and whether configuration can change without downtime is answered on the live FAQ. Automated hub failover is on the roadmap, not a shipped feature.
What happens when a fault occurs: hub, rule, session, dictionary or site
Five situations cover what a connectivity team worries about day to day: what happens on Quazar, and what you do.
One hub down
Each hub holds isolated storage and configuration, so a fault inside it does not cross into the other hubs it connects to over FIX.
Configuration and rules are stored and reloadable, and routes are managed through the REST API without a restart. Quazar does not publish a hub recovery runbook; automated hub failover is on the roadmap. Ask the team how recovery is handled in your deployment.
A bad rule deployed
Configuration and rules are stored and reloadable, with rollback to the last known-good configuration.
Roll back to the last known-good configuration.
A counterparty session drops
A durable store covers the essential message set, new orders, allocations and drop copy, so a restart or failover does not lose in-flight state.
Once the session is re-established, use replay to recover in-flight messages.
A dictionary change
Data dictionary changes apply without restarting the session that carries them.
Push the updated dictionary live; other counterparties sharing its hub stay connected throughout.
A site outage
The technical brochure lists multi-node clustering with state replication, and cross-site and multi-region replication, among Quazar's resilience capabilities (Quod Financial, September 2026). What a given deployment supports is a question for the team.
Configuration and rules are stored and reloadable, and routes are managed through the REST API without a restart. Quazar does not publish a hub recovery runbook; automated hub failover is on the roadmap. Ask the team how recovery is handled in your deployment.
How can we consolidate FIX routing, transformation, session management, and monitoring into one platform?
Consolidating routing, transformation, session management and monitoring onto one platform also consolidates failure risk, so failover and redundancy belong on the selection checklist from the start.
When routing, transformation, session management and monitoring move from separate bridges, scripts and homegrown routers onto a single fabric, the properties that keep a fault inside that fabric matter as much as the feature list. On Quazar those properties sit at the hub level, described on the topology page: run one hub or many, each self-contained, interconnected over native FIX rather than a shared transport. A team evaluating consolidation should ask the fault-containment and rollback questions above for each layer being merged, since a shared transformation engine or a shared monitoring layer can quietly reintroduce the single point of failure that separate hubs were built to avoid.
How long does it take to migrate to a new FIX connectivity platform, and what are the risks?
Quod Financial does not publish a migration timeframe. Duration depends on the number of counterparties, dialects and rules moved, and the continuity risk is a fault on a newly moved route reaching counterparties that have not moved yet.
Because Quazar hubs are self-contained, migration can proceed hub by hub, or region by region, since each hub keeps its own isolated storage and configuration. If a newly migrated hub misbehaves, the response is a rollback to the last known-good configuration, and message replay from store, file or memory covers recovery. Firms that prefer not to run the cutover can have Quod Financial operate it, with operations delivered against defined service levels; see services for scope.
What's available today, and what's only on the roadmap?
Fault isolation between hubs is available today. Automated failover between hubs is not: it is on Quazar's roadmap.
The distinction matters because the two are easy to blur in conversation. Isolation is a property of how hubs are built: self-contained storage and configuration keep a fault from crossing into another hub by design, true today on every deployment. FIX failover is an action, moving live traffic away from a failed hub automatically without an operator deciding to do it, and Quazar's product page lists that capability as on the roadmap, not a shipped feature. The technical brochure lists multi-node clustering with state replication, and cross-site and multi-region replication, among Quazar's resilience capabilities (Quod Financial, September 2026). What a given deployment supports is a question for the team.
Continuity questions
What is fault isolation in Quazar's FIX fabric?
Fault isolation means each hub holds its own storage and configuration, so a fault inside one hub stays inside that hub rather than crossing into the others. There is no shared single point of failure between hubs.
Is automated hub failover available today?
No. Automated hub failover is on Quazar's roadmap. Configuration and rules are stored and reloadable, and routes are managed through the REST API without a restart. Quazar does not publish a hub recovery runbook; ask the team how recovery is handled in your deployment.
Can I roll back a bad configuration change?
Yes. Quazar's live FAQ states that configuration changes are applied through the REST API or GUI with no restarts, and that configuration rollback is built in.
What happens to in-flight messages if a session drops?
Messages can be replayed from the store, from file, or from memory, so an operator can recover in-flight state instead of rebuilding it from the counterparty's side.
Can a data dictionary change without restarting a live session?
Yes. Data dictionary changes apply without restarting the session that carries them, so other counterparties sharing the same hub are undisturbed.
Does Quazar support multi-node clustering or cross-site replication?
According to the Quazar technical brochure, deployments can use multi-node clustering with state replication, and cross-site and multi-region replication: a deployment choice, separate from automated hub failover, which is on the roadmap.
Where should FIX high availability sit in an RFP for connectivity?
Ask how faults are isolated, how configuration is rolled back, and which resilience features are shipped versus planned, rather than inferring it from a throughput number. Quod Financial can also run operations against defined service levels; see the services page.
Sources
- quazar.org/product, read 8 October 2026.
- quazar.org/faq, read 8 October 2026.
- quazar.org/services, read 8 October 2026.
- Quod Financial, Quazar technical brochure, September 2026.