# topology
`src/core/topology/api.rs`
Shard routing for thread-per-core deployments. Determines which core owns a given node ID, enabling disjoint `StorageHandle` instances to each serve a subset of nodes without coordination.
---
## Types
```rust
pub type CoreId = u16;
pub type ShardId = u16;
pub struct ThreadCoreRequest {
pub core_id: CoreId,
pub shard_count: u16,
}
impl Default for ThreadCoreRequest {
// core_id: 0, shard_count: 1
}
impl ThreadCoreRequest {
pub fn owned_shard(&self) -> ShardId
// Returns: core_id % shard_count
}
```
---
## Routing Functions
```rust
pub fn shard_for_node(node_id: u64, shard_count: u16) -> ShardId
```
Deterministic: `node_id % shard_count`. Returns `0` if `shard_count` is 0.
```rust
pub fn request_owns_node(request: &ThreadCoreRequest, node_id: u64) -> bool
```
Returns `true` if the shard that owns `node_id` matches the shard owned by `request`.
---
## Example
```rust
// 4-core setup
let shard_count = 4u16;
let core0 = ThreadCoreRequest { core_id: 0, shard_count }; // owns shard 0
let core1 = ThreadCoreRequest { core_id: 1, shard_count }; // owns shard 1
assert!(request_owns_node(&core0, 4)); // 4 % 4 == 0
assert!(request_owns_node(&core1, 9)); // 9 % 4 == 1
assert!(!request_owns_node(&core0, 9));
```
---
## Notes
These types are also re-exported from `storage::api` as `CoreId`, `ShardId`, and `ThreadCoreRequest` for convenience — callers working entirely within the storage layer do not need to import `core::topology` directly.
Thread-per-core sharding is an optional scale-up feature. In single-core deployments use `ThreadCoreRequest::default()` (one shard, core 0) which routes all node IDs to a single `StorageHandle`.