[设计 / Design] 多写者、复制与高可用边界评估 / evaluate multi-writer, replication, and high availability

中文说明

版本、顺序与当前进度

版本待定 / P2 / deferred，不再将探索池命名为 v1.0 发布承诺。必须由真实多写者/可用性需求与独立 RFC 进入；当前单写者语义继续作为近期版本边界。

问题

当前是单机、单写者、单进程独占；并发读最多 8；没有复制、多写入者或高可用。中等业务一旦需要多实例部署、滚动升级不中断写、或跨机房容灾，就无法直接使用。这是刻意的边界（DESIGN.md 首版不含多写者/复制），但在“生产规模化探索”里应评估是否、以及如何进入。

范围

• 评估目标形态与最小可行切片：只读副本/跟随者、单写者 + 复制、还是真正的多写者；明确一致性模型（单写者串行、租约、还是 Raft 类共识）。
• 复用现有稳定 key/RowId/sequence、幂等 receipt 与 cursor 身份；评估在复制/选主下这些身份与 exactly-once effect 的语义。
• 明确与当前单请求原子、migration、compact、backup 的交互，以及冲突/故障恢复边界。
• 先产出 RFC 与可复现实验，证明收益与代价；不预设实现承诺，不破坏现有单机部署。

验收条件

• RFC 冻结目标一致性模型、身份/幂等语义、故障与恢复边界。
• 至少一个原型或模拟实验给出吞吐/延迟/恢复代价数据。
• 明确哪些现有 API/格式契约必须演进，哪些保持兼容。
• 若不采纳，明确结论与理由。

English Description

Version, sequence, and current progress

Version TBD / P2 / deferred, not a v1.0 release promise. Require real multi-writer/availability demand and an independent RFC; retain current single-writer semantics for near-term releases.

Problem

The system is single-node, single-writer, single-process with up to 8 concurrent reads and no replication, multi-writer, or high availability. As soon as a medium business needs multiple instances, rolling upgrades without write interruption, or cross-datacenter disaster recovery, it cannot be used directly. This is an intentional boundary (DESIGN.md excludes multi-writer/replication in v1), but production scale exploration should evaluate whether and how to change it.

Scope

• Evaluate target shapes and a minimal slice: read replicas/followers, single-writer plus replication, or true multi-writer; define the consistency model (single-writer serialization, leases, or consensus).
• Reuse existing stable keys/RowIds/sequences, idempotency receipts, and cursor identity; evaluate their semantics and exactly-once effect under replication/failover.
• Define interaction with request atomicity, migration, compaction, and backup, plus conflict and recovery boundaries.
• Produce an RFC and reproducible experiments proving benefit and cost; make no implementation commitment and preserve the existing single-node deployment.

Acceptance Criteria

• An RFC freezes the target consistency model, identity/idempotency semantics, and failure/recovery boundaries.
• At least a prototype or simulation provides throughput/latency/recovery cost data.
• It states which API/format contracts must evolve and which stay compatible.
• If rejected, state the decision and rationale.

Start with DESIGN.md and the current single-writer semantics described in the issue. Define the consistency, identity, idempotency, failure, and recovery boundaries, then produce an RFC and a reproducible prototype or simulation. Done means the RFC, cost data, compatibility impact, and adoption or rejection rationale satisfy all acceptance criteria.