Delivery Semantics

This chapter explains what FLUX guarantees today and how those guarantees evolve over time.

Message Ordering

• ordering is guaranteed per partition
• ordering is not guaranteed across partitions
• key-based hashing keeps same-key events on same partition

Producer Acknowledgment Modes

FLUX supports:

• acks=0: fire-and-forget style acceptance
• acks=1: leader append acknowledgment
• acks=all: waits for committed progress by ISR rules

Committed Visibility

Consumers read only up to partition high watermark.

Effect:

• uncommitted leader-only appends are not visible to CONSUME
• visible data tracks committed replication progress

Consumer Group Commit Semantics

Offset commits require:

• active member identity
• current generation id
• partition ownership validation

This prevents stale members from committing offsets after rebalance.

Current Guarantee Level

Today FLUX provides at-least-once style delivery behavior at application level.

Why:

• consumer retries + reprocessing are possible
• producer retries can duplicate records without idempotent producer keys

Not Yet Implemented

• idempotent producer semantics
• transactional producer/consumer coupling
• exactly-once processing guarantees

Practical Guidance

• use stable keys for per-entity order
• design consumers to be idempotent
• commit offsets only after business side effects succeed