A transaction groups changes into a unit with defined atomicity and isolation behavior. Relational systems commonly provide multi-row transactions; document databases vary in transaction scope and cost. A transaction is useful when related state must change together, such as debiting one account and crediting another.

Constraints such as unique keys, foreign keys, and check constraints protect invariants at the data boundary. Application-level checks alone can race: two requests may both observe that a username is free and then attempt to insert it. A unique constraint is the final authority.

Keep transactions short and avoid slow network calls inside them. For workflows spanning independent services, a single database transaction may not be available; use patterns such as sagas, reservations, compensating actions, and reconciliation instead of pretending the whole workflow is atomic.