High Availability and Leasing
Conncentric enforces a Single Writer principle: only one active instance per configuration is allowed at any given time. This is managed through a system called Lease-Based Fencing.
Why This Matters
In financial messaging, running two copies of the same session simultaneously causes duplicate messages, sequence number conflicts, and reconciliation failures. The leasing system guarantees that exactly one adapter instance owns each session at any time, and if it fails, another takes over cleanly.
How Failover Works
- An adapter claims a session from the Orchestrator and receives a lease.
- The adapter maintains the lease by checking in with the Orchestrator at regular intervals.
- If the adapter stops checking in (crash, network partition, pod eviction), the Orchestrator marks the lease as expired after a configurable timeout.
- A standby adapter detects the expired lease and claims the session.
- If the original adapter recovers, it discovers its lease has been revoked and shuts down immediately, preventing split-brain.
Failover Timing
Failover time equals the lease timeout plus the time to establish the new session.
Configuration
Lease timing is configurable based on the environment.
| Environment | Recommended leaseTtlSeconds |
|---|---|
| Development | 15 |
| Production | 20–30 |
Deployment Modes
| Mode | Behavior |
|---|---|
| Single | One active instance. No standby instances are provisioned. |
| Exclusive (Active/Passive) | One active instance processes traffic, while one or more standbys are ready to take over. Required for protocols that need exclusive access. |
| Load Balanced (Active/Active) | Multiple instances share the workload concurrently. Used for protocols that support distributed processing. |
Select the deployment mode when creating an adapter. For Exclusive mode, run at least two adapter pods so a standby is always available.