Skip to content

CONCEPT Cited by 1 source

Heartbeat-based ownership

Heartbeat-based ownership represents the owner of a mutable resource (an IP address, a partition, a capacity slot) as a list of non-overlapping (owner, t_start, t_end) time ranges, continuously refreshed by heartbeats from the data plane. Attribution at time t becomes a time-range lookup.

Structure

map: resource_id → sorted, non-overlapping list of
    { owner_id, t_start, t_end }

Invariants:

  • A resource cannot belong to two owners at the same moment → non-overlapping intervals.
  • The list is sorted ascending by t_start for O(log n) lookup.
  • Each heartbeat either extends the current trailing range (same owner, bumps t_end) or starts a new range (different owner; previous range's t_end is frozen at last heartbeat).

Advantages over discrete events

  • Self-healing. A delayed or lost heartbeat at time t leaves a gap in the range; a subsequent heartbeat fills or extends the map without any compensating event. No catch-up logic required.
  • No ordering dependency. Heartbeats can arrive out of order; the map remains correct because each heartbeat is a self-contained (owner, t_start, t_end) statement, not a delta.
  • Disposable state. A new consumer can rebuild the map purely from recent heartbeats — no need to replay history from durable storage. Canonical payoff: systems/netflix-flowcollector runs on 30 instances with no persistent storage.
  • Graceful degradation. Missed heartbeats produce unattributed results, not misattributed ones — the resource is marked uncertain rather than incorrectly assigned.

When this pattern applies

Whenever:

  1. You can observe or produce a steady stream of (owner, t_start, t_end) claims from the data plane — i.e. the operation you care about already implies current ownership.
  2. Temporary gaps in ownership knowledge are tolerable as long as they don't silently become wrong answers.

Canonical wiki instance

  • systems/netflix-flowcollector maps IP → list of (workload_id, start, end) time ranges; every TCP flow close heartbeats the local IP's current owner; cluster-wide Kafka broadcast shares heartbeats; remote-IP lookup keys on the flow's start timestamp.

Contrast

Seen in

Last updated · 319 distilled / 1,201 read