multi-pod destinations, generic load metric, hash member records

[marcopiraccini]

Summary

Breaking 0.2.0 overhaul. No backwards-compatible layer.

A destination is now served by a set of pods (1:N), not a single binding. Member records are hashes that carry both the address and an opaque integer load metric. Locks get their own Valkey record so transaction-bound calls route correctly when a destination is fanned out. The registry sits behind an LRU+TTL cache. Helpers are rewritten on top of the new API.

The library is now domain-neutral: identifiers and field names no longer assume databases. The PostgreSQL case is preserved as a worked example in the design doc.

Also: Apache 2.0 LICENSE + publishConfig.access: public so the package can be released to npm as OSS, and a generic coordinator-pattern.md design doc linked from the README. CI now runs on Node 22, 24, and 26.

Data model

• <prefix>:member:<id> — hash with address and load. Heartbeat is an atomic HSET + EXPIRE pipeline.
• <prefix>:destination:<id> — set of pod ids. Sole source of truth for routing. No separate binding key.
• <prefix>:lock:<lockId> — hash with podId, destinationId, and lock metadata.

Documentation

• New coordinator-pattern.md at the repo root, linked from the README. Generic 3-tier design note covering caller / coordinator / resource pod, failover, fan-out, transactions and locks, and Kubernetes platform notes.
• Includes a "Worked example: PostgreSQL connection pool" section mapping every abstract concept to the database case (resource pod -> PG pool pod, destination -> tenant, load -> pool.openCount(), lock id -> opaque token for the pinned PG connection, etc.).

[mcollina]

lgtm