Skip to main content

Replication

This page describes FLUX replication semantics as implemented today.

Replication Status (Current)​

FLUX replication currently combines:

  1. in-memory replication manager for ISR/high watermark/ack semantics
  2. local replica segment mirroring (same node) for storage visibility

This is not yet multi-broker network replication.

Implemented Behavior​

  • leader offset tracking per partition
  • follower progress updates through REPLICA_FETCH
  • ISR membership computed from lag + freshness
  • high watermark computed from ISR offsets
  • acks=1 and acks=all produce handling
  • committed-read behavior (CONSUME only up to high watermark)
  • under-replicated partition signaling
  • partition role transitions (leader / follower)
  • produce rejection on follower role (NOT_LEADER)

Key Semantics​

  • leader replica id is implicit 0
  • follower ids are 1..(replication_factor-1)
  • acks=all succeeds only when:
    • high watermark reaches produced offset
    • ISR size is at least min.insync.replicas
  • ISR eligibility requires:
    • follower ack seen within replica lag timeout
    • offset lag <= max replica lag

TypeScript SDK View​

In normal application usage, replication behavior is consumed through TypeScript producer APIs:

import { FLUXClient } from '@flux/typescript-sdk';

const client = new FLUXClient({ host: '127.0.0.1', port: 9092 });
await client.connect();

await client.produce('orders', 'user1', 'created', 'all');

If replication cannot satisfy acks=all, the produce call surfaces REPLICATION_TIMEOUT.

Not Implemented Yet​

  • broker-to-broker network replication
  • quorum-backed replica metadata
  • cross-node failover with automatic leadership transfer
  • persistent replication state across clustered brokers

Planned Direction​

Replication will graduate to true networked replication with control-plane metadata quorum in Phase 4 and beyond.