State that lives in your Orleans cluster and converges without locks.

Orleans.Lattice is a sorted, durable, horizontally-scalable key-value store embedded in your Orleans cluster. Its conflict resolution is algebraic, so any cluster can accept a write to any key with no lock manager and no consensus round trip. Run it on one machine, then active-active across regions, with the same ILattice code.

Two concurrent G-Counter increments meeting at their join. An order diagram shaped like a diamond. At the bottom is the shared starting state, A=0 and B=0, value 0. Cluster A adds 3 to its own component, reaching A=3, B=0, value 3. Cluster B, at the same time, adds 5 to its own, reaching A=0, B=5, value 5. Neither of those states is above the other. Merging takes the larger value for each replica, so both paths rise to the same top state, A=3, B=5, value 8.

Both clusters hold A=3, B=5, value 8. Either order of delivery reaches the same join.

The G-Counter example from the CRDT guide. Merge takes the larger value per replica, so it is commutative, associative, and idempotent.

Orleans.Lattice in three minutes

Why Orleans.Lattice exists, what it is, and where to start.

Length
Captions
English
Transcript
On its companion page, with the code it shows
Download
MP4, 11.6 MB

All videos

Three ways in

Each way in is a chain of pages in reading order. Start at its first node, or join it wherever you already are.

Build

You have chosen Orleans.Lattice and are writing code against ILattice.

  1. Quick start Register Lattice on a silo, then read and write your first keys.
  2. API reference The public ILattice interface, batch operations, options, and serializable types.
  3. Configuration Options, per-tree overrides, immutability constraints, and the storage provider. Also on Operate
  4. Predicate operations Server-side filters for typed reads, conditional writes, scans, cursors, and range deletes.
  5. CRDT primitives Counters, registers, sets, and maps that resolve concurrent writes by construction.
  6. Atomic writes All-or-nothing batches across keys, shards, trees, and replicating clusters.
  7. Samples Runnable projects, grouped by concern.

Evaluate

You are deciding whether the platform fits, and want the evidence.

  1. What it is and why it exists The store, the problem it solves, and the three positions it takes.
  2. A core plus seams How companion packages fill documented seams, and why one you leave out costs nothing.
  3. Consistency guarantees The contract for what a caller of ILattice observes, operation by operation.
  4. Chaos tests A live cluster under concurrent load, topology changes, network partitions, and storage faults.
  5. Verified atomic commit The commit protocol's deterministic core, machine-checked with Coyote and a TLA+ specification.
  6. Single-silo performance Measured throughput and latency against real Azure Tables.
  7. Reference architecture An active-active, cross-region estate on Azure Container Apps, with a deployment kit.

Operate

You run a Lattice estate and need it sized, observed, and recoverable.

  1. Configuration The options reference and per-tree overrides. Also on Build
  2. Tree sizing Resize a live tree's leaf and internal-node limits, with an undo window.
  3. WAL tuning How the write-ahead log's concurrency limits meet a durable backend's throughput envelope.
  4. Multi-silo scaling What each workload gains as silos are added, measured on real Azure Storage.
  5. Metrics Runtime telemetry through System.Diagnostics.Metrics, for any OpenTelemetry exporter.
  6. Dashboards Bundled Grafana dashboards for the Lattice meters.
  7. Troubleshooting Symptom-driven diagnosis, starting from a DiagnoseAsync report.
  8. Disaster recovery Recovering backups after losing the cluster that took them.
  9. Explorer console An auth-aware web console over the cluster's gRPC APIs, with capability-gated admin areas. in progress

One programming model, Local to Global

A deployment grows in three stages. The code that reads and writes data resolves ILattice and calls it in all three; each stage adds companion packages and configuration, not a rewrite.

  1. Local

    One machine, no cloud account, no external services.

  2. Team

    A shared cluster with real users, so identity, policy, and data shape start to matter.

  3. Global

    Multiple regions, each serving reads and writes.

Programming model ILattice unchanged at every stage

A core plus seams

Storage, identity, governance, replication, administration, and observability are companion packages behind documented seams. A host takes only what it registers; a capability it leaves out costs nothing.

  • Core3 packagesOrleans.Lattice, GrainIndex, Vector
  • APIs21 packagesApi.Abstractions, Api.State, Api.State.Grpc, Api.Data, and 17 more
  • MCP4 packagesApi.Mcp, Api.Mcp.Apps, Api.Mcp.Telemetry, Api.Mcp.Telemetry.Azure
  • AI / RepoContext2 packagesApi.Mcp.RepoContext, Api.Mcp.RepoContext.Replication
  • Explorerin progress6 packagesExplorer.Web, Explorer.Core, Explorer.UI, Explorer.AppKit, and 2 more
  • Identity and Security5 packagesAuth, Membership, Membership.Oidc, Membership.Entra, and 1 more
  • Governance3 packagesSchema, Tenancy, Apps
  • Replication2 packagesReplication, Replication.Grpc
  • Storage4 packagesStorage.AzureTable, Storage.File, Backup.AzureBlob, Caching.AzureBlob
  • Operations3 packagesBackup, Scaling, Dashboards

Browse every package in the documentation map, or install from the package inventory.

New here?

The overview explains what the platform is, why it exists, and how a deployment grows from one machine to many regions. Every capability is catalogued in Features, each with its documentation and, where one exists, a runnable sample.