Daptin

Home / Product / Clustering and distributed state

Coordinate more than one node

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

Share cache entries, live event fanout, counters, and queue claims across every Daptin node.

See what it changesTechnical guide ↗
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

Share caches, event fanout, counters, and queue claims so every Daptin node sees the same runtime state.

With more than one application instance, a change on node A may need to reach a WebSocket on node B. Give rate counters, permission caches, and queue claims a cluster-wide shared view.

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. Use Daptin clustering for shared runtime state and provide highly available databases, storage, networking, and load balancing.

01

Keep live clients connected across nodes

Distribute relevant product events through shared PubSub.

02

Make selected controls cluster-aware

Coordinate counters and short-lived work claims.

03

Synchronize permission caches, rate counters, and background claims across the cluster.

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

Give every node the same view of permission caches, rate counters, live events, and background claims.

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

Works better together

Realtime events

Carry live application change across node boundaries.

Explore Realtime events →Works better together

Traffic controls

Coordinate selected request counters across the cluster.

Explore Traffic controls →Works better together

Monitoring

Observe each node and the shared dependencies between them.

Explore Monitoring →
Know the boundary

What Daptin leaves in your hands.

Combine Daptin clustering with redundant databases, shared storage, load balancing, health checks, capacity planning, and recovery tests. Operate peer discovery, load balancing, shared databases, shared storage, rolling updates, capacity, and cluster recovery tests.

Understand the operating responsibility →

Build from one foundation

Add Daptin nodes while caches, counters, live events, and queue claims stay coordinated.

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

Get DaptinExplore all capabilities