Home / Product / Clustering and distributed state

Coordinate more than one node

Keep live updates and shared runtime decisions coordinated across Daptin nodes.

Use the distributed runtime for cache, live event fanout, counters, and shared claims when one application instance is no longer the whole topology.

See what it changes Technical guide ↗

Clustering and distributed state in a product

Run more than one nodeSeveral Daptin instances serve the application

Share short-lived runtime stateCache, topics, counters, and work claims

Keep clients seeing one systemCoordinate live behavior across the cluster

Nodes share the runtime context that must cross them

01Fan out live changesReach connected clients on more than one node.

02Coordinate shared controlsUse distributed counters and claims for cross-node behavior.

03Refresh cached decisionsInvalidate relevant runtime state when the application changes.

Why it matters

Adding nodes should not create several independent versions of the same live backend.

With more than one application instance, a change on node A may need to reach a WebSocket on node B. Rate counters, permission caches, and queue claims also need a shared view or the cluster behaves like unrelated servers.

Daptin uses Olric-backed distributed state for cache, PubSub, counters, and claims, with configured peer discovery. This supports live fanout and coordination for selected runtime concerns.

The shared database and storage remain separate architectural responsibilities. Clustering coordinates Daptin nodes; it does not automatically make every dependency highly available.

Keep live clients connected across nodes

Distribute relevant product events through shared PubSub.

Make selected controls cluster-aware

Coordinate counters and short-lived work claims.

Reduce stale runtime decisions

Invalidate configured caches when underlying policy or content changes.

How it fits

Part of one connected backend.

Clustering and distributed state does more when it can reuse the records, people, access rules, and workflows already in your application.

Step 1Discover

Nodes join through the configured peer topology.

Step 2Share

Use distributed cache, topics, counters, and claims.

Step 3React

Propagate relevant changes and invalidations.

Step 4Depend

Continue to rely on the chosen database, storage, and network architecture.

What it enables

Use it in products people recognize.

Start from the experience you want to create; the backend capability supports the work behind it.

Horizontally served API

Place several Daptin nodes behind a load balancer.

Clustered realtime product

Reach live subscribers regardless of the node holding their connection.

Shared outbox processing

Reduce duplicate work with a cluster-visible claim.

Connected by design

Build the next part without starting over.

These capabilities share the same application context, so each one makes clustering and distributed state more useful.

Know the boundary

What Daptin leaves in your hands.

Clustering is not automatic high availability. You own peer networking, discovery, load balancing, shared database and storage, split-brain risks, rolling changes, capacity, and recovery testing.

Understand the operating responsibility →

Build from one foundation

Make clustering and distributed state part of the product—not another disconnected service.

Run Daptin locally, explore the live administration surface, and follow one complete application path.

Get Daptin Explore all capabilities