Architecture

XCON Quee is a thin, correctness-focused broker over the xcon-db log engine. It owns delivery; xcon-db owns truth.

Engine truth, RAM delivery plane

Everything durable — messages, cursors, subscription state, tokens, topology — lives in xcon-db. The broker holds only a live delivery plane in RAM: sessions, credits, in-flight tracking, backoff. A crash loses nothing acknowledged; the broker rebuilds its plane from the engine on restart.

One writer per topic

Each topic has a single writer goroutine that batches publishes into one INSERT — a single engine fsync, crash-atomic. The engine stamps each row an arrival-ordered sequence (x_seq); that sequence is the cursor unit. One writer per topic is what makes the sequence and the cursor unambiguous.

One session per subscription

Each subscription is served by one session that feeds from the engine (SYNC feed), dispatches to its workers under a credit window, and checkpoints its cursor. Workers share the session round-robin, so each message goes to exactly one worker (competing consumers). A second subscription on the same topic is an independent fan-out with its own cursor.

Fenced ownership

A subscription's cursor is guarded by a compare-and-swap fence in the engine. If two brokers race for the same subscription, the compare-and-swap elects one owner; the loser stands down. A session dispatches only while it holds a live ownership lease, so a fenced-out or partitioned broker stops delivering on its own. This is why a handoff neither loses nor double-commits acknowledged work.