DSM

Appearance

Developer Guide ​

This guide is for engineers wiring DSM into a service boundary and deciding how much of the stack they need to expose.

Start With dsm-core ​

The main integration contract lives in dsm-core:

  • DsmRuntime
  • DsmRuntimeBuilder
  • CollectionSpecBuilder
  • LeaseCollectionSpecBuilder
  • CrdtCollectionSpecBuilder
  • collection handle interfaces such as DsmRegister, DsmLeaseRegister, and DsmCrdtCollection

Runtime Flow ​

The typical flow is:

  1. your application mutates a collection handle
  2. DsmRuntime stamps metadata and records the change
  3. the sync layer replicates deltas over the platform channel
  4. data-plane repair brings lagging peers back toward the current view

Entity Modeling Rules ​

  • Prefer immutable records.
  • Use withMetadata(...) and withLeaseState(...) to produce new values.
  • Keep codecs deterministic.
  • Model collection identity explicitly with tenant, application, and collection IDs.

When To Use Which Integration Path ​

Use standalone wiring when DSM is embedded into a service that already owns its bootstrapping and lifecycle.

Use Spring Boot when your platform model standardizes around property-driven configuration, bean wiring, and lifecycle management.

Testing Guidance ​

Tests in this repository prefer in-memory collaboration over mocks. Before inventing new scaffolding, look at:

  • FakeClusterMembership
  • RuntimePlatformSyncService
  • the integration harnesses in dsm-integration-test

Best References In The Repository ​

  • dsm-examples for runnable standalone and Spring Boot examples
  • TwoNodeIntegrationTest for register replication across nodes
  • RuntimeIntegrationTest for broader register, lease, and CRDT coverage