Waku Relay vs Store: Choosing Message Delivery for Decentralized Apps

The offline window forces a Relay vs Store choice

When building on Waku the core engineering decision is whether to rely on Waku Relay or add Waku Store. The problem is the offline window: if a peer is not connected when a message is published, Relay will not deliver it. Without persistence the message is lost to that peer.

The useful takeaway is to use Relay for low-latency, ephemeral broadcasts where occasional loss is acceptable, and Store for asynchronous interactions where delivery must survive temporary disconnections.

Relay and Store compared

Both implementations share the same message envelope format and content-topic filtering, so application encoding and decoding can stay unchanged.

Feature	Waku Relay	Waku Store
Delivery model	Push via GossipSub	Pull store-and-forward
Persistence	None, ephemeral	Disk-based temporary
Latency	Ultra-low	Higher request/response
Reliability	Best-effort	Guaranteed within stored window
Resource cost	Low bandwidth/RAM	Higher disk I/O and storage

Trade-offs for real-time vs asynchronous use

Choose Relay when

Waku Relay uses GossipSub to broadcast messages to all subscribed peers. It provides low-latency delivery but no persistence. It is suitable for real-time chat presence updates or telemetry where occasional loss is acceptable.

Choose Store when

Waku Store adds a store-and-forward layer on top of Relay, allowing offline message retrieval at the cost of higher storage and bandwidth. It is appropriate for asynchronous interactions like forums or notifications that require guaranteed delivery.

Validate the behavior locally

Validation requires running both components and simulating a disconnect.

Start a Relay node

Run in a terminal with execution permission for the waku binary and network access to localhost.

waku relay --listen-address /ip4/127.0.0.1/tcp/8000/ws

Risk: binding to a local port requires no other process to use 8000.

Start a Store node

Run in a separate terminal. The Store ingests messages from the Relay gossip stream.

waku store --listen-address /ip4/127.0.0.1/tcp/8001/ws --relay-address /ip4/127.0.0.1/tcp/8000/ws

Risk: Store writes to disk; ensure adequate free space.

Check persistence

1. Subscribe a waku-js client to a content topic.
2. Disconnect the client.
3. Publish a message to Relay/Store while disconnected.
4. Reconnect and use the Store fetch method to retrieve messages missed while offline.

A practical check is to measure latency and bandwidth with the waku-bench tool to compare Relay-only versus Store configurations under identical load.

Limitations and practical checks

• Relay does not guarantee message delivery if a peer is offline at the time of publish.
• Store nodes require disk space and may become a bottleneck if many peers rely on a single store.