> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sqd.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Scheduling and replication

> How the current scheduler maps archival chunks to worker nodes.

The scheduler produces an **assignment**: a versioned description of the datasets,
chunks, workers, and worker copies used by the Network. Workers use it to manage
their local storage. Portal uses it to find workers for a requested block range.

## Inputs to an assignment

The current production scheduler uses:

* the worker set and the latest reported worker status;
* the chunks discovered in the configured dataset storage locations;
* each chunk's size, weight, and optional minimum worker version;
* configured worker capacity, storage saturation, and minimum replication.

It first calculates a target copy count for each chunk weight from the available
capacity. The target is bounded by the configured minimum and the total worker
count. Version and per-worker capacity constraints can reduce the copies actually
placed or cause scheduling to report that capacity is insufficient.

It then uses a deterministic hash-based placement algorithm with per-worker
capacity limits. The same inputs produce the same assignment. Consistent hashing
keeps many placements unchanged when the worker set changes, but it does not mean
that every change moves only a small amount of data.

```mermaid theme={"system"}
flowchart LR
  chunks["Chunks and sizes"] --> scheduler["Scheduler"]
  workers["Workers and capacity"] --> scheduler
  config["Replication settings"] --> scheduler
  scheduler --> artifact["Versioned assignment"]
  artifact --> worker["Worker storage plan"]
  artifact --> portal["Portal routing table"]
```

## What can change an assignment

An assignment can change when:

* a worker joins or leaves the worker set;
* new chunks appear in a dataset;
* a worker version changes which chunks it can serve;
* storage capacity, saturation, minimum replication, or chunk weights change.

If only a small input changes and the replication counts remain the same, the
hash-based placement can preserve most existing copies. If a capacity change causes
a replication count to change, many chunk-to-worker mappings can change at once.

## How nodes apply it

The published Network state identifies the current compressed assignment. Workers
and Portal poll that state and fetch a new artifact when its identifier changes.

A worker looks up its own peer ID, calculates the chunks it should hold, and starts
the required downloads. Portal reads chunk ranges and worker peer IDs to construct
its routing view. The assignment is therefore both a storage plan and a routing
input, although workers and Portal read different fields from it.

<Note>
  The scheduler repository also contains a feature-gated multistep scheduler and
  design documents. Those documents explicitly mark production wiring as work in
  progress. This page describes the current production path in
  `src/scheduling.rs`.
</Note>

## Implementation sources

* [Production scheduling code](https://github.com/subsquid/network-scheduler/blob/master/src/scheduling.rs)
* [Current reshuffling analysis](https://github.com/subsquid/network-scheduler/blob/master/docs/chunk-reshuffling.md)
* [Assignment format and transport](https://github.com/subsquid/sqd-network/tree/main/crates/assignments)
* [Worker assignment polling](https://github.com/subsquid/worker-rs/blob/master/src/controller/assignments.rs)

Continue with [How a query is
served](/en/network/introduction/how-a-query-is-served) to see how Portal uses the
routing view.


## Related topics

- [From blocks to chunks](/en/network/introduction/blocks-to-chunks.md)
- [SQD Network components](/en/network/introduction/network-components.md)
- [Changelog](/changelog.md)
- [Reliability and monitoring](/en/network/introduction/reliability-and-monitoring.md)
- [What happens onchain and offchain](/en/network/introduction/onchain-and-offchain.md)