ACID

Outcome: Design or review ACID for this system while keeping data correct, secure, and easy to operate. User context: An inventory hold writes both the reservation and stock change, or neither. A rule keeps stock at zero or above. Serializable isolation stops two checkouts from both taking the last item. Recovery keeps the result after commit. Load tests still check the database's real behavior. Technical concept or control: ACID. Why it fits: Use all four ideas as questions. Then write down the real constraints, isolation level, commit reply, and recovery promise. Do not use it when: “ACID compliant” is not one complete yes-or-no promise. Database consistency also does not make every business rule correct by itself. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.