Keep related changes consistent
For example, transferring a balance requires both the debit and credit to succeed together. If only one change is committed, the stored state no longer represents the intended operation.
A transaction can also protect a multi-step update that reads a value and then writes a dependent result. Where concurrent changes are possible, use the isolation or locking behavior appropriate to the database and business rule.
Avoid long or external work inside the transaction
Do not keep a transaction open while waiting for a user, a network service, or a lengthy computation. Long-running transactions can hold resources and complicate concurrent work.
External email, payments, or file uploads generally cannot be rolled back by a database rollback. Coordinate those effects with explicit states, an outbox, or a compensating action, and test what happens if the process stops between steps.