Innomerc Choose your depth. Learn at your own pace.
Understand it
Imagine moving ten points from one game account to another. Subtracting the points but failing to add them would leave an incorrect result. A database transaction groups related changes so they can be committed together or rolled back.
The example uses fictional points, not banking instructions. If a required operation fails, the application must handle the failure and ensure the transaction is rolled back rather than leaving an unfinished plan.
Under the hood
BEGIN starts an explicit transaction; COMMIT completes it and ROLLBACK discards its changes. Concurrent transactions involve isolation rules and may require retries. A database transaction does not automatically make a message to another external service atomic with the database change.
Practitioner perspective
Test interruption, concurrent updates and retry behavior against business invariants. A response lost after commit can leave the caller uncertain about the result; blind retries can repeat an operation. Use appropriate idempotency and reconciliation designs across service boundaries.
Database Transactions
Imagine moving ten points from one game account to another. Subtracting the points but failing to add them would leave an incorrect result. A database transaction groups related changes so they can be committed together or rolled back.
Illustrated analogy · Select the image to enlargeWatch it work
A fictional, simplified model. Select a component to inspect it, or follow the steps in order.
Two changes, one transaction.
Example: ten fictional game points move between two records. This is a database model, not a payment service.
The application groups the dependent updates in one database transaction.
How to use this example
Select Next step to read at your own pace, or Animate step to watch one exchange. Nothing advances until you choose.
What it means
Everyday example
State in this scenario
Inspect components & read every step
- Game service
The fictional application requesting a points transfer.
Example: It asks the database to subtract and add points as one transaction.
- Database
An organized store of records that software can read and update.
Example: A shop stores product quantities and order records.
- Result
The outcome produced by the operation in this example.
Example: Read the current state and the step explanation to see what succeeded or failed.
Both changes commit
The application groups the dependent updates in one database transaction.
- Game service Database: BEGIN + changes. Subtract from one fictional record and add to the other within the transaction.
- Game service Database: COMMIT. The successful transaction is committed as one unit.
- Database Result: Success. The result reports a completed database transaction.
A condition fails
The application discards the transaction when a required condition is not satisfied.
- Game service Database: BEGIN + check. The application begins and checks the required conditions.
- Game service Database: ROLLBACK. A required condition fails, so the transaction is rolled back.
- Database Result: Not completed. The result explains that this attempted transfer did not commit.
Fictional teaching trace. One moving dot represents an exchange, not a measured network capture.
Open the detailed lesson walkthrough
Explore the system
Begin
Start a transaction for the fictional points transfer.
Read every step without animation
Commit
- Begin. Start a transaction for the fictional points transfer.
- Changes. Apply both related updates with the required checks.
- Commit. Make the completed transaction’s changes durable.
Both related changes belong to one transaction.
Rollback
- Begin. Start the group of related changes.
- Failure. A required condition is not met.
- Rollback. Discard the uncommitted changes.
A failed attempt should not leave half a transfer.
Attack view
Two concurrent requests pass a balance check based on stale state and attempt inconsistent updates.
Defender view
- Group dependent changes and enforce invariants within an appropriate concurrency design.
- Test failures before and after commit and make retries safe for the business operation.
Common mistakes
- Atomicity does not replace authorization.
- A database transaction does not roll back every external side effect.
Check your understanding
Active recall: explain this idea in 30 seconds
Imagine moving ten points from one game account to another. Subtracting the points but failing to add them would leave an incorrect result. A database transaction groups related changes so they can be committed together or rolled back.
Now give an example and name one limitation. Revisit the explanation if you get stuck.
Primary sources
Original explanations informed by these specifications and official resources. Source versions and lesson review are separate from product updates.
Content reviewed 2026-09-10. Read the editorial policy.