# Architecture principles whose category is Transactions / State / Concurrency

> 13 records

This index as JSON: https://banes-lab.com/json/api/facets/architecture/category/transactions-state-concurrency

## Entries

- [Idempotency](https://banes-lab.com/records/architecture/idempotency.md): A design rule that repeating an operation with the same input has the same effect as running it once.
- [Atomicity](https://banes-lab.com/records/architecture/atomicity.md): A design rule that the steps of a state change either all take effect or none do.
- [ACID](https://banes-lab.com/records/architecture/acid.md): A conceptual representation of the four guarantees of a database transaction: atomicity, consistency, isolation and durability.
- [Transaction Boundary](https://banes-lab.com/records/architecture/transaction-boundary.md): A rule or precondition that a transaction covers exactly the writes of one unit of work inside one service.
- [Unit of Work Pattern](https://banes-lab.com/records/architecture/unit-of-work-pattern.md): A design pattern that collects the changes of one use case and commits them together in a single transaction.
- [Consistency](https://banes-lab.com/records/architecture/consistency.md): The degree to which stored data satisfies its invariants after every change.
- [Isolation](https://banes-lab.com/records/architecture/isolation.md): A rule or precondition that concurrent transactions do not see each other's uncommitted changes, to the degree the isolation level declares.
- [Concurrency Control](https://banes-lab.com/records/architecture/concurrency-control.md): A mechanism that coordinates concurrent access to shared state, through locks, versions or compare-and-swap.
- [Optimistic Locking](https://banes-lab.com/records/architecture/optimistic-locking.md): A design pattern that checks a record's version when it is written and rejects the write if another writer changed it first, comparing only the writer's own span where a surface is fenced per writer.
- [Pessimistic Locking](https://banes-lab.com/records/architecture/pessimistic-locking.md): A design pattern that locks a record before reading it for update, so other writers wait until the transaction ends.
- [State Isolation](https://banes-lab.com/records/architecture/state-isolation.md): A design rule that each piece of mutable state belongs to one unit of concurrent execution, so no two units that run at the same time can write it.
- [Controlled Side Effects](https://banes-lab.com/records/architecture/controlled-side-effects.md): A design rule that mutation, I/O and persistence happen at declared boundaries, around a core of pure functions.
- [Petri Nets](https://banes-lab.com/records/architecture/petri-nets.md): A conceptual representation of concurrent flow as places holding tokens and transitions that consume and produce them, which can be analyzed for deadlock.