HeiKyu/Rendezvous
2
0
Fork 0
Code Issues 27 Pull Requests Actions Packages Projects Releases Wiki Activity

Design shared state and deterministic routing for HA and multi-region #28

New Issue
Open
opened 2026-07-16 22:17:17 +02:00 by Kyuubi · 0 comments
Kyuubi commented 2026-07-16 22:17:17 +02:00
Owner
Copy Link
Copy Source

Parent: #1
Identified by: #23

Classification

Post-v1. Rendezvous v1 remains one active process with bounded in-memory state and one advertised mediator endpoint.

Trigger

Start this work when the 99.5% single-active objective is insufficient, planned maintenance must preserve listings, or a region needs multiple active mediator endpoints.

Outcome

Design and implement shared TTL/CAS state, deterministic attempt-to-mediator routing, fencing/ownership, failover semantics, and multi-node consistency before making any HA, active-active, or multi-region claim.

Acceptance criteria

  • State ownership and split-brain behavior are specified and adversarially tested.
  • HTTP and UDP for one attempt route to compatible authoritative state.
  • Failover preserves documented safety and privacy invariants.
  • Multi-node capacity, restart, partition, and recovery evidence is versioned.
  • Deployment and rollback docs make the supported topology explicit.
Parent: #1 Identified by: #23 ## Classification Post-v1. Rendezvous v1 remains one active process with bounded in-memory state and one advertised mediator endpoint. ## Trigger Start this work when the 99.5% single-active objective is insufficient, planned maintenance must preserve listings, or a region needs multiple active mediator endpoints. ## Outcome Design and implement shared TTL/CAS state, deterministic attempt-to-mediator routing, fencing/ownership, failover semantics, and multi-node consistency before making any HA, active-active, or multi-region claim. ## Acceptance criteria - State ownership and split-brain behavior are specified and adversarially tested. - HTTP and UDP for one attempt route to compatible authoritative state. - Failover preserves documented safety and privacy invariants. - Multi-node capacity, restart, partition, and recovery evidence is versioned. - Deployment and rollback docs make the supported topology explicit.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Kyuubi schmidt.florian (Florian Schmidt)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: HeiKyu/Rendezvous#28
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?