Topic: In all-to-all topology, changes reach every node in one hop (no re-queueing needed for coverage); in ring topology, propagation takes N-1 hops — explore how this affects convergence latency and conflict probability

Date: 2026-05-29

Time: 14:15

Now I have enough context from both the multi-leader replication and gossip protocol modules. Here's the explanation.

Topics to Explore

• [function] multi-leader-replication/multileader.py:applyremotechange — The heart of conflict detection and the pending re-enqueue that enables ring propagation; trace through the LWW vs CUSTOM_MERGE branches
• [function] gossip-protocol/gossipprotocol.py:receivegossip — Compare the heartbeat-monotonicity merge rule (line 55-78) with multi-leader's _seen-based idempotency; both prevent stale data from overwriting fresh state, but through different mechanisms
• [general] custom-merge-cascade-in-ring — What happens when CUSTOM_MERGE generates a synthetic change with a new timestamp that itself conflicts at the next hop? Whether this can cause convergence to exceed N-1 rounds
• [file] vector-clocks/vector_clock.py — Scalar Lamport clocks can't distinguish concurrent from causally ordered writes; vector clocks would let the system detect true concurrency and avoid false conflicts in ring propagation
• [general] gossip-vs-anti-entropy — This codebase's gossip uses random pairwise exchange (rumor mongering); anti-entropy protocols periodically reconcile full state, which guarantees convergence at the cost of bandwidth

Beliefs

• all-to-all-converges-in-one-round — ALLTOALL topology delivers every pending change to every other node in a single sync() call, achieving convergence in one round when no custom-merge cascades occur
• ring-requires-n-minus-one-rounds — RING topology advances changes by exactly one hop per sync() round due to snapshot-isolated pending queue draining, requiring N-1 rounds for a single-source change to reach all N nodes
• ring-requeues-via-apply-remote-change — applyremotechange appends accepted changes to the receiving node's _pending list, enabling store-and-forward propagation in ring topology; without this, changes would stop at the first hop
• topology-does-not-change-conflict-outcome — Both topologies use the same deterministic (timestamp, node_id) comparison for LWW resolution; topology affects when and where conflicts are detected, not which value wins
• longer-convergence-widens-conflict-window — Ring topology's O(N) convergence time means additional writes can arrive during propagation, increasing the chance of further conflicts compared to all-to-all's single-round window