How do you decide what belongs inside a database transaction in an ASP.NET Core API?

In production I define the invariant, commit point, and every failure before selecting transaction APIs. Isolation and lock behavior are scoped to that boundary, and commands acquire shared resources in a consistent order. I account for uncertain commit outcomes by using operation ids or verification rather than blindly replaying a write. Cancellation may stop work before commitment, but after a durable commit the workflow continues independently of the request. Telemetry captures transaction duration, lock waits, retries, and state transitions without logging every routine read. Tests cover rollback within the database plus recovery across process crashes and duplicate external delivery. I use a saga or compensating action only when the workflow truly spans independently committed systems, not for a simple multi-table save.