Stage 3 · Build

Databases & Persistence

Transactions

Use BEGIN, COMMIT, ROLLBACK, isolation levels, SELECT FOR UPDATE, and retryable conflicts.

8 min readBuilding Backend ApplicationsBuild

Why Transactions

Transactions ensure that a group of operations either all succeed or all fail. Without transactions, partial failures leave your data in inconsistent states. A payment might deduct money without creating an order, or an order might be created without inventory being reserved.

Basic Transactions

Gousing-database/sql-transactions.go

36 linesLn 1, Col 1Go

BeginTx starts a transaction. defer tx.Rollback() ensures cleanup if anything fails. Commit finalizes the transaction. If Commit succeeds, Rollback becomes a no-op.

Error Handling

Transaction error handling is critical. If any operation fails, the transaction must be rolled back. The defer tx.Rollback() pattern handles this automatically. But you must still check Commit errors.

Goproper-error-handling-in-transactions.go

33 linesLn 1, Col 1Go

Check RowsAffected to verify the operation succeeded. If the sender has insufficient funds, affected is 0 and the transaction rolls back.

Isolation Levels

Isolation levels control how transactions see each other's changes. Higher isolation prevents more anomalies but reduces concurrency. Choose the minimum isolation level that correctness requires.

Level	Anomalies Prevented	Use Case
Read Uncommitted	None	Almost never
Read Committed	Dirty reads	Default for most databases
Repeatable Read	Non-repeatable reads	Financial calculations
Serializable	All anomalies	Critical consistency required

Pessimistic Locking

SELECT FOR UPDATE locks rows so other transactions cannot modify them until your transaction completes. Use this when you read-then-write and need to prevent concurrent modifications.

Goselect-for-update-pattern.go

29 linesLn 1, Col 1Go

FOR UPDATE acquires an exclusive lock on the row. Other transactions trying to SELECT FOR UPDATE on the same row will block until this transaction commits or rolls back.

Retryable Conflicts

Serializable transactions can fail with serialization errors when two transactions try to modify the same data concurrently. The correct response is to retry the entire transaction.

Gotransaction-retry-pattern.go

37 linesLn 1, Col 1Go

PostgreSQL error code 40001 is serialization_failure. Retry with exponential backoff. After max retries, return an error to the client.

Keep transactions short

Long-running transactions hold locks and block other transactions. Do all non-database work (HTTP calls, file I/O) outside the transaction. Only begin the transaction when you are ready to write.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.