# The lex records whose category is transactions-state-concurrency

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

## Entries

- [Idempotency Key or Deterministic Operation](https://banes-lab.com/records/lex/idempotency-key-or-deterministic-operation.md): The requirement that an operation carry a deduplication key or be deterministic so repeating it is safe.
- [Non-Repeatable Side Effects](https://banes-lab.com/records/lex/non-repeatable-side-effects.md): Side effects whose repetition changes the outcome, so retrying an operation double-applies them.
- [Safe Retries](https://banes-lab.com/records/lex/safe-retries.md): The ability to retry an operation without fear of duplicating its effects.
- [State Tracking](https://banes-lab.com/records/lex/state-tracking.md): The degree to which making operations idempotent requires tracking processed keys or prior state.
- [All-or-Nothing State Change](https://banes-lab.com/records/lex/all-or-nothing-state-change.md): The ability to apply a set of changes so that either all of them take effect or none do.
- [Distributed Scalability](https://banes-lab.com/records/lex/distributed-scalability.md): The degree to which enforcing atomic transactions across nodes limits how far a system can scale out.
- [Partial Commit](https://banes-lab.com/records/lex/partial-commit.md): Committing only some of a multi-step change after a failure, leaving state half-updated and inconsistent.
- [BASE/Eventual Consistency](https://banes-lab.com/records/lex/base-eventual-consistency.md): A consistency model favoring availability and soft state, letting replicas converge over time rather than staying strongly consistent.
- [Distributed Availability](https://banes-lab.com/records/lex/distributed-availability.md): The degree to which insisting on strong transactional consistency reduces availability across a distributed system.
- [Durability](https://banes-lab.com/records/lex/durability.md): The degree to which committed data survives crashes and is never lost once acknowledged.
- [Strong Transactional Guarantees](https://banes-lab.com/records/lex/strong-transactional-guarantees.md): The ability to guarantee that a group of operations is atomic, consistent, isolated, and durable.
- [Consistency Rules](https://banes-lab.com/records/lex/consistency-rules.md): The requirement that the invariants a transaction must preserve be defined for its scope.
- [Hidden Distributed Transaction](https://banes-lab.com/records/lex/hidden-distributed-transaction.md): A transaction that silently spans service boundaries, coupling systems that should commit independently.
- [Large Transaction Scope](https://banes-lab.com/records/lex/large-transaction-scope.md): The degree to which widening a transaction to cover more work increases contention and failure surface.
- [Safe State Mutation](https://banes-lab.com/records/lex/safe-state-mutation.md): The ability to mutate state within a bounded transaction so partial failures cannot corrupt it.
- [Coordinated Persistence](https://banes-lab.com/records/lex/coordinated-persistence.md): The ability to commit a set of related changes together as one atomic unit of work.
- [Repository Complexity](https://banes-lab.com/records/lex/repository-complexity.md): The degree to which coordinating saves through a unit of work adds indirection to the persistence layer.
- [Scattered Save Calls](https://banes-lab.com/records/lex/scattered-save-calls.md): Persisting related changes through many independent save calls, so a mid-sequence failure leaves partial state.
- [Inconsistent Replicas/Models](https://banes-lab.com/records/lex/inconsistent-replicas-models.md): Replicas or models that disagree on the same data, so reads return conflicting answers.
- [Reliable State](https://banes-lab.com/records/lex/reliable-state.md): The ability to trust that stored state always satisfies its invariants.
- [Dirty Reads/Writes](https://banes-lab.com/records/lex/dirty-reads-writes.md): Reading or overwriting another transaction's uncommitted changes, so a rollback leaves corrupt data.
- [Safe Concurrent Operations](https://banes-lab.com/records/lex/safe-concurrent-operations.md): The ability to run concurrent transactions without their intermediate states interfering.
- [Safe Parallel Mutation](https://banes-lab.com/records/lex/safe-parallel-mutation.md): The ability to let multiple actors mutate shared state in parallel without corrupting it.
- [Shared State Identification](https://banes-lab.com/records/lex/shared-state-identification.md): The requirement that all state shared between concurrent actors be identified before it is guarded.
- [Blind Overwrite](https://banes-lab.com/records/lex/blind-overwrite.md): Writing over another actor's update without checking whether the data changed first, silently losing it.
- [Conflict Detection](https://banes-lab.com/records/lex/conflict-detection.md): The ability to detect that data changed since it was read, so a conflicting write can be rejected.
- [Retry Complexity](https://banes-lab.com/records/lex/retry-complexity.md): The degree to which rejecting conflicting writes pushes retry-and-merge logic onto callers.
- [Version Field](https://banes-lab.com/records/lex/version-field.md): A field on a record whose value changes on each write, used to detect concurrent modification.
- [Deadlocks](https://banes-lab.com/records/lex/deadlocks.md): The degree to which acquiring multiple locks pessimistically risks two holders waiting on each other forever.
- [Lock Ownership](https://banes-lab.com/records/lex/lock-ownership.md): The requirement that a lock be exclusively held by one actor for the duration of a critical section.
- [Lock-Free Throughput](https://banes-lab.com/records/lex/lock-free-throughput.md): The degree to which a design sustains high throughput by coordinating concurrent access without holding locks.
- [Strong Conflict Prevention](https://banes-lab.com/records/lex/strong-conflict-prevention.md): The ability to prevent conflicting updates by locking data before it is modified.
- [Concurrency Safety](https://banes-lab.com/records/lex/concurrency-safety.md): The degree to which isolating state per unit keeps concurrent execution free of races.
- [Data Sharing](https://banes-lab.com/records/lex/data-sharing.md): The degree to which strictly isolating state limits components from directly sharing data.
- [Effect Boundaries](https://banes-lab.com/records/lex/effect-boundaries.md): The requirement that side effects be confined to explicit boundaries rather than scattered through pure logic.
- [Performance Optimization](https://banes-lab.com/records/lex/performance-optimization.md): The degree to which pushing side effects to the edges can forgo in-place optimizations that mutate for speed.
- [Pure Core / Imperative Shell](https://banes-lab.com/records/lex/pure-core-imperative-shell.md): An arrangement that keeps decision logic pure and pushes all side effects to a thin outer shell.
- [Ad-Hoc Lock Ordering](https://banes-lab.com/records/lex/ad-hoc-lock-ordering.md): Ordering lock acquisition by hand-reasoning rather than a proven scheme, inviting deadlock.
- [Concurrency Correctness](https://banes-lab.com/records/lex/concurrency-correctness.md): The degree to which concurrent flows produce correct results free of races and lost updates.
- [Concurrent-Flow Modeling](https://banes-lab.com/records/lex/concurrent-flow-modeling.md): The ability to model concurrent token flow explicitly so its behavior can be analyzed.
- [Deadlock Freedom](https://banes-lab.com/records/lex/deadlock-freedom.md): The degree to which a concurrent design is provably free of states where progress halts permanently.
- [Modeling Overhead](https://banes-lab.com/records/lex/modeling-overhead.md): The degree to which formally modeling concurrency as a net adds effort over writing the code directly.
- [Places and Transitions](https://banes-lab.com/records/lex/places-and-transitions.md): The requirement that a modeled system be expressed as places holding tokens and transitions that move them.
- [Reachability and Deadlock Analysis](https://banes-lab.com/records/lex/reachability-and-deadlock-analysis.md): The ability to analyze which states a concurrent model can reach and whether any of them deadlock.