Skip to content

Architecture Review: Leader Election Watch Channel Design (v0.2.0) #209

Closed
2 of 2 issues completed
Closed

Description

@JoshuaChi

Context

This ticket is for comprehensive architecture review of the leader election watch
channel design in Node struct (v0.2.0 release).

Current implementation uses watch::channel with a kept-alive receiver (_leader_elected_rx)
to prevent channel closure.

Scope

  • Analyze current design: watch::channel + kept-alive rx pattern
  • Review tokio watch channel lifecycle semantics
  • Evaluate performance implications (ns-level precision)
  • Determine if lazy subscription is needed
  • Evaluate broadcast::channel as alternative
  • Consider resource overhead when no subscribers exist
  • Document final architecture decision

Key Questions

  1. Performance: watch vs broadcast vs other approaches?
  2. Resource efficiency: Should system compute when no subscribers exist?
  3. API clarity: Does _leader_elected_rx pattern make sense semantically?
  4. Simplicity: Can we simplify without sacrificing performance?

Acceptance Criteria

  • Architecture decision documented
  • Performance characteristics understood
  • Implementation plan (if changes needed) agreed upon

Activity

  1. added this to the v0.2.0 milestone on Dec 16, 2025
  2. added theissue type on Dec 16, 2025
  3. added 3 commits that reference this issue on Dec 17, 2025
    15e3878
    f911e35
    9151f5a
  4. added 16 commits that reference this issue on Dec 26, 2025
  5. added a commit that references this issue on Jan 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    raft-electionLeader election mechanism and related issues

    Type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions