# Data Model: Multi-Raft (Static → Split → Move)

## Entities

- **Store**
  - `id: u64`
  - `addr: String`
  - Holds multiple `Peer` instances (one per `Region` replica) and reports status to PD.

- **Region**
  - `id: u64`
  - `start_key: bytes`
  - `end_key: bytes` (empty = infinity)
  - `voters: Vec<u64>` (store IDs)
  - `leader_id: u64`
  - `approx_size_bytes: u64`

- **Peer**
  - `store_id: u64`
  - `region_id: u64`
  - `raft_state: HardState, ConfState`
  - `pending_eventual: VecDeque<(ns_id, key, value, ts)>`

- **Placement Metadata (PD)**
  - `stores: [Store]`
  - `regions: [Region]`
  - `move_directives: [(region_id, from_store, to_store)]`

## Relationships

- Store 1..* Peer (per Region replica)
- Region 1..* Peer (across Stores)
- PD owns canonical Region→Store mapping and Move directives.

## Lifecycle

- **Bootstrap**: PD returns initial `regions` → Store creates Peers and persists meta.
- **Split**: Region exceeds threshold → Split command commits → two Region metas persisted → new Peer created.
- **Move**: PD issues `MoveRegion` → leader adds replica on target store (ConfChange Add) → replica catches up → old replica can be removed via ConfChange Remove.

## Constraints

- Region key ranges must be non-overlapping and sorted.
- Raft storage/logs are prefixed by `region_id` to avoid cross-region collisions.
- Quorum required for writes; ConfChange operations must preserve quorum at each step.