Database Transaction Sequence
The code
sequenceDiagram
autonumber
participant S as Application Service
participant T as Transaction Manager
participant D as Database
S->>T: Begin transaction
T->>D: Update accounts table
T->>D: Insert ledger entry
alt All statements succeed
S->>T: Commit
T->>D: Commit transaction
D-->>T: Acknowledged
T-->>S: Transaction complete
else Constraint violation
S->>T: Rollback
T->>D: Rollback transaction
T-->>S: Transaction failed
end
Note over S,D: Isolation level is read committed
How this template works
This template shows the life of a database transaction: the service begins one, the transaction manager applies two statements, and then the flow splits into commit or rollback depending on whether every statement succeeded. It is the diagram to attach to any code path that moves money, decrements stock, or otherwise must not half-happen. Backend teams use it in design reviews to agree on where the transaction boundary sits, and it is a surprisingly effective teaching tool for developers who have used an ORM for years without seeing the begin and commit underneath.
The syntax demonstrates a block whose branches are outcomes rather than user choices. Three lifelines are declared: participant S as Application Service, participant T as Transaction Manager, and participant D as Database. The setup is unconditional — S->>T: Begin transaction, then two statements T->>D: Update accounts table and T->>D: Insert ledger entry. Two messages from the same sender to the same receiver in a row are perfectly legal and read as sequential statements. Then alt All statements succeed opens the happy path: the commit travels S->>T, then T->>D, the database acknowledges with a dashed arrow, and the manager reports T-->>S: Transaction complete. The else Constraint violation branch is deliberately shorter — a rollback request, the rollback itself, and a failure report — because there is nothing left to acknowledge. end closes the block, and Note over S,D: Isolation level is read committed spans all three lifelines to record the concurrency setting everyone always forgets to write down.
The gotcha is the rollback branch’s honesty. It is tempting to draw only the commit path and mention rollback in prose, but the diagram is precisely where reviewers check that the failure path returns a distinct signal to the caller. The second trap is the Note participant list: Note over S,D uses the declared ids, not the display names, and the ids must match exactly or the parser rejects the line.
To adapt it, add a savepoint exchange for services that support partial rollback, insert a lock manager participant if row locking needs documenting, or change the note to your actual isolation level.
Related templates: the microservice call sequence shows the service layer that opens transactions like this one, the data pipeline flowchart covers the batch jobs that read the committed rows, and the banking ledger ER diagram models the tables these statements touch. The sequence diagram guide has the complete block syntax.
