Skip to content

Conversation

@enigbe
Copy link
Contributor

@enigbe enigbe commented Nov 1, 2025

What this PR does

In this PR we introduce TierStore, a three-tiered (KVStore + KVStoreSync) implementation that manages data across three distinct storage layers based on criticality.

Background

As we have moved towards supporting remote storage with VssStore, we need to recognize that not all data has the same storage requirements. Currently, all data goes to a single store which creates some problems:

  • Remote storage adds latency on every read/write operation
  • Network graph and scorer data is ephemeral and easily rebuild-able from the network
  • Persisting ephemeral data to remote storage wastes bandwidth and adds unnecessary latency
  • Users persisting to remote storage have no local disaster recovery option

This PR proposes tiered storage that provides granular control over where different data types are stored. The tiers include:

  • Ephemeral store (network graph, scorer): optional fast local storage to avoid remote latency
  • Primary store (channels, payments, wallet): preferably remote storage for critical data
  • Backup store: optional (preferably local) backup for disaster recovery, with data written to (removed from) lazily to avoid blocking primary data operations

Additionally, we also permit the configuration of Node with tiered storage allowing callers to:

  • set retry parameters,
  • set backup and ephemeral stores, and to
  • build the Node with a primary store.
    These configuration options also extend to our foreign interface, allowing bindings target to build the Node with their own (KVStore + KVStoreSync) implementations. A sample Python implementation is provided and tested.

Concerns

  1. Nested Retry Logic: VssStore has built-in retry logic. Wrapping it in TierStore creates nested retries.
  2. Backup Queue Capacity: Currently hard-coded (100 in prod, 5 in tests). Ideally this should be configurable but there are concerns about exposing this to callers? What is a sensible default?
  3. Data Consistency Between Primary and Backup: Backup operates asynchronously and may lag behind or miss operations if the queue overflows. Should we consider adding a background sync task to reconcile backup with primary? Expose metrics for backup lag/queue depth? Implement catch-up logic on startup?
  4. Exposing KVStore to the FFI

Related Issues

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Nov 1, 2025

I've assigned @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

@ldk-reviews-bot ldk-reviews-bot requested a review from tnull November 1, 2025 23:18
@ldk-reviews-bot
Copy link

🔔 1st Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

@enigbe enigbe force-pushed the 2025-10-tiered-data-storage branch 2 times, most recently from 12fc8c3 to 4896773 Compare November 4, 2025 08:36
Introduces TierStore, a KVStore implementation that manages data
across three storage layers:

- Primary: Main/remote data store
- Ephemeral: Secondary store for non-critical, easily-rebuildable
  data (e.g., network graph) with fast local access
- Backup: Tertiary store for disaster recovery with async/lazy
  operations to avoid blocking primary store

Adds four configuration methods to NodeBuilder:

- set_tier_store_backup: Configure backup data store
- set_tier_store_ephemeral: Configure ephemeral data store
- set_tier_store_retry_config: Configure retry parameters with
  exponential backoff
- build_with_tier_store: Build node with primary data store

These methods are exposed to the foreign interface via additions
in ffi/types.rs:

- ffi::SyncAndAsyncKVStore: Composed of KVStore and KVStoreSync
  methods to handle the types::SyncAndAsyncKVStore supertrait
  across FFI
- ffi::ForeignKVStoreAdapter and ffi::DynStore: Adapt/translate
  between foreign language store and native Rust store
- Conditional compilation for DynStore: ffi::DynStore with uniffi,
  types::DynStore without, with selection aided by the wrap_store!()
  macro
@enigbe enigbe force-pushed the 2025-10-tiered-data-storage branch from 4896773 to 29f47f3 Compare November 4, 2025 21:53
This commit adds unit, integration, and FFI tests
for the TierStore implementation:
- Unit tests for TierStore core functionality
- Integration tests for nodes built with tiered storage
- Python FFI tests for foreign key-value store
@enigbe enigbe force-pushed the 2025-10-tiered-data-storage branch from 29f47f3 to 264aa7f Compare November 4, 2025 22:07
@ldk-reviews-bot
Copy link

🔔 2nd Reminder

Hey @tnull! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants