Waku v2 meshsub heartbeat limits in high-churn production environments

Answer

Confirmed facts: Waku v2 uses libp2p gossipsub meshsub; heartbeatInterval controls the periodic IHAVE/IWANT maintenance tick (default ≈1 s in js‑libp2p, ≈0.7 s in go‑libp2p); fanoutTTL defaults to 60 s and only caches publisher IDs for topics you do not subscribe to. Load‑balancer idle timeouts cut long‑lived gossip streams regardless of heartbeat cadence, and the libp2p connection manager enforces max/min connection limits independent of fanoutTTL.

Likely explanation for production tuning: In high‑churn settings keep the heartbeatInterval in the range where control traffic stays manageable but mesh repair can keep pace with peer turnover – roughly 0.5 s to 2 s. Below ~0.5 s the per‑topic control overhead and CPU rise sharply; above a few seconds graft/prune lag increases mesh‑partition and loss risk. FanoutTTL should be set short enough to avoid holding stale publisher entries that compete for scarce connection slots, yet long enough to avoid frequent rebuilds that add first‑publish latency; a practical band is 20 s–90 s for publishing nodes, while relay‑only subscribers can leave it at the default.

1. Measure or set the load‑balancer idle timeout to be longer than the longest expected quiet period on your topics (or enable TCP keepalives/libp2p ping so idle streams are not torn down).
2. Pick a heartbeatInterval starting point: 1 s for js‑waku, 0.7 s for go‑waku/nwaku; then test within 0.5 s–2 s while observing mesh size, graft/prune rates and message loss under churn.
3. If the node publishes, tune fanoutTTL: begin with the default 60 s and reduce toward 20 s if you see many stale fanout entries consuming connection‑manager slots; increase toward 90 s if first‑publish latency spikes after idle periods.
4. Verify that the libp2p connection manager’s max connections is sufficient for the sum of active mesh peers plus fanout‑cached peers; adjust the manager limits only if you consistently hit the ceiling.

One missing detail that changes the recommendation: which Waku client (nwaku, go‑waku, js‑waku) and version you are running, and whether the nodes act as publishers or relay‑only subscribers. Fanout tuning only matters for publishing nodes; relay‑only subscribers should focus on discovery, prune backoff and connection‑manager limits instead.