Why Database Transactions Must Wrap Entire Operations, Not Individual Queries

A software engineering lab demonstrates how omitting database transactions can leave systems in a partially completed, inconsistent state after a failure. In the example, a payment flow inserts a payment record and marks an order as paid before crashing, but never records the wallet transaction — resulting in corrupted data rather than a clean rollback. The core lesson is that a database transaction acts as a boundary: all related writes inside it either commit or roll back together, while statements executed outside any transaction cannot be automatically undone. A safer implementation wraps all three related writes — payment insert, order status update, and wallet transaction insert — inside a single transaction, ensuring the database reverts to its original state if any step fails. The lab also applies the same principle to an outbox pattern, where an invoice update and an outbox event insert are committed atomically to guarantee consistency between business state and event intent.