Tonbo’s manifest control plane is built directly on top of object-store compare-and-swap semantics. On S3-compatible backends, CAS is effectively the only atomic primitive available to us, and both write/flush publication and compaction publication depend on optimistic transaction retries when a commit loses the race. This makes manifest CAS behavior part of Tonbo’s core execution cost, not just an implementation detail.
We need concrete measurement here, not intuition. The open question is whether the current fusio-manifest transaction path is efficient enough for production-oriented workloads once retry pressure, contention, and object-store latency are included. In particular, we need to understand the cost profile of successful commits vs retried commits, how that cost changes with concurrency, and whether CAS-heavy paths become a practical bottleneck for Tonbo’s write and compaction loops.
This work should produce measurements that answer:
- What is the latency and throughput profile of manifest CAS commits under representative contention levels?
- How often do optimistic transactions retry, and what is the retry amplification cost?
- What is the object-store request cost shape per successful logical commit?
- Under what workload or contention envelope does CAS become operationally risky or inefficient?
- Is the current approach good enough for the next Tonbo release, or does it require follow-up design work before calling it production-ready?
Expected Outcome
A short write-up with data, test conditions, and conclusions about the efficiency and production suitability of the current CAS-based manifest path, including any clear risk boundaries or follow-up recommendations.
Tonbo’s manifest control plane is built directly on top of object-store compare-and-swap semantics. On S3-compatible backends, CAS is effectively the only atomic primitive available to us, and both write/flush publication and compaction publication depend on optimistic transaction retries when a commit loses the race. This makes manifest CAS behavior part of Tonbo’s core execution cost, not just an implementation detail.
We need concrete measurement here, not intuition. The open question is whether the current fusio-manifest transaction path is efficient enough for production-oriented workloads once retry pressure, contention, and object-store latency are included. In particular, we need to understand the cost profile of successful commits vs retried commits, how that cost changes with concurrency, and whether CAS-heavy paths become a practical bottleneck for Tonbo’s write and compaction loops.
This work should produce measurements that answer:
Expected Outcome
A short write-up with data, test conditions, and conclusions about the efficiency and production suitability of the current CAS-based manifest path, including any clear risk boundaries or follow-up recommendations.