# Expected Diagnosis: write-latency-during-concurrent-upsert

The expected result should converge on the case-specific mechanism below while
keeping conclusions bounded by the collected evidence.

## Expected conclusion

Concurrent upserts repeatedly updated the same aggregate row, creating unavoidable pessimistic-lock contention on one row/region. A second table amplified each write across four secondary indexes, increasing locked KV entries and commit work. Key scattering or more nodes cannot split one existing hot row; the workload must shard or aggregate differently and reduce index/write amplification.

## Required evidence chain

- Identify concurrent updates to the same logical row as the dominant contention mechanism.
- Explain why one row remains on one region and cannot be split by SHARD_ROW_ID_BITS, AUTO_RANDOM, or leader scattering.
- Quantify the extra KV writes and locks introduced by secondary indexes and indexed soft-delete columns.
- Recommend application-level sharding/aggregation, lower concurrency, and reducing unnecessary indexes.