Clustering

Share runtime behavior across Daptin instances.

Use Olric when several server processes need distributed caching, PubSub delivery, and shared rate counters.

Add nodes for a measured reason

Multiple Daptin processes add coordination, network, rollout, and failure modes. First make the database and file storage durable, put one instance behind health-aware routing, and measure the capacity or availability need that another node addresses.

Configure Olric discovery and ports

Daptin uses embedded Olric for shared cache, PubSub, and counters. Configure peers with -olric_peers as comma-separated host:membership_port values, or use -olric_seed for hostname-based discovery. Set -olric_port when automatic derivation is unsuitable; membership uses the following port. Choose -olric_env for the intended local, LAN, or WAN network profile and restrict these ports to cluster members.

./daptin \
  -port=:6336 \
  -olric_port=5336 \
  -olric_peers=node-a.internal:5337,node-b.internal:5337 \
  -olric_env=lan

Give every node the same application schema, database, compatible configuration, and access to the intended file storage. Do not use one writable SQLite file as a shared multi-node database.

Know what is shared and what can degrade

ConcernCluster roleFailure question
CacheReduces repeated reads and coordinates invalidation.Can stale/local fallback change behavior during partition?
PubSubCarries realtime and internal notifications between nodes.What live updates are delayed or lost when coordination fails?
Rate countersShares configured request counts across healthy nodes.Does fallback multiply the effective allowance per process?
Background workLeases/deduplication coordinate eligible workers.Can retries or failover repeat an external side effect?

Test normal and degraded operation

  1. Start at least two nodes and confirm cluster membership in logs.
  2. Write through one node and read through another using the shared database.
  3. Subscribe through one node and produce a relevant event through another.
  4. Exercise a shared rate limit across both routes.
  5. Stop one node, interrupt a peer path, and observe requests, counters, events, and background work.
  6. Restore the node and verify convergence before declaring recovery.
Define fail-open and fail-closed expectations. A cluster outage can turn one shared allowance into local allowances and can interrupt live delivery. Document which degraded behaviors are acceptable for your application.

What clustering shares

Cache

Coordinate cached application data rather than isolating every instance.

PubSub

Carry live notifications between clients connected to different instances.

Rate counters

Apply shared traffic accounting instead of a separate allowance on every process.

Plan failure behavior

Configure discovery and networking, and test node loss in the target environment.

Design the deployment before adding nodes.