5.2 Partitioning: Request Processing

A routing layer maps client reads and writes to the node that owns the relevant partition.

1. Requests With a Shard Key

For create, read, update, or delete operations that contain the partition/shard key:

1. derive the logical partition from the key;
2. resolve the partition’s current owner;
3. send or forward the request to that node;
4. execute the operation locally on the target partition.

This is the efficient path because the system can identify the destination without contacting unrelated partitions.

2. Requests Without a Shard Key

A predicate that does not contain a routable key may require scatter/gather:

1. send the query to many or all relevant partitions;
2. execute locally;
3. merge, sort, aggregate, or reconcile results at the coordinator.

This can make an otherwise cheap query scale with the number of partitions.

3. Secondary Indexes

3.1 Local / Document-Partitioned Index

Each partition indexes only its own records. Writes are local, but a query by that secondary field may need scatter/gather across partitions.

3.2 Global / Term-Partitioned Index

Index entries are partitioned independently from the base records. A secondary-key lookup can route to the index partition, but writes now update another distributed structure and must handle its consistency and failure semantics.

Partition-key design and secondary-index design must therefore be considered together.