From e7efa91cbcee3fae441bccbda9519a4e14bb9568 Mon Sep 17 00:00:00 2001 From: John Coffey Date: Sat, 19 Sep 2026 10:01:34 -0700 Subject: [PATCH] Scale-out storage decision: sharded stores first, read-replica routing after per-domain directories, with configured replicas reported at startup meanwhile (ST-2) --- docs/spec/features/scale-out-storage.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/docs/spec/features/scale-out-storage.md b/docs/spec/features/scale-out-storage.md index e5624b0..92e4427 100644 --- a/docs/spec/features/scale-out-storage.md +++ b/docs/spec/features/scale-out-storage.md @@ -173,6 +173,11 @@ Each requirement has an ID, and tests name the IDs they check. with `readReplicas` or `Sharded` either works as this spec says, or the server reports why at startup (ST-15, ST-23, ST-29). Silently ignoring a configured replica or shard, as the fork does today, isn't allowed. + **Decision** (2026-09-19): built in two steps. Sharded stores (ST-16 to + ST-29) come first; read-replica routing (ST-5 to ST-15) follows after + per-domain directories (feature 9). Until then each configured replica is + reported at startup with an error event naming it, saying replicas aren't + used yet, and every operation goes to the primary. - **ST-3.** Composite stores are transparent. Every check on what kind of backend a store is answers as its primary does (for replicas) or as its members do (for shards): `Store::id()`, `is_sql()`, `is_pg_or_mysql()`,