Concurrent Balance-Update Race Prevention

negative) when retry exhaustion is reached then 503 with error code concurrency_retry_exhausted.

Several processes update the same parent aggregate concurrently - e.g., two payment applications hit one vendor's open balance, or parallel sync workers adjust an account summary. Without a concurrency guard the second write can clobber the first (lost update), leaving the parent balance wrong. The system serializes the read-modify-write of any customer-visible running total using row-level locking (SELECT … FOR UPDATE) or an optimistic version/updated_at check that aborts and retries on conflict, so the final balance reflects every contributing child transaction.

Given a vendor balance row and two concurrent payment application requests submitted in parallel;
when both requests land simultaneously;
then exactly one wins and updates the balance, the other is retried or returns 409, and the final balance equals the sum of all posted child transactions;
(negative) when retry exhaustion is reached then 503 with error code concurrency_retry_exhausted.

account_balance { id: string, account_id: string, entity_id: string, balance_minor: int64, currency_code: char(3), version: int64, updated_at: timestamp };
child payment lines sum to balance_minor;
(reference, product may differ).

POST /v1/payments with row-level lock on parent balance; -> 201 on success; -> 409 optimistic_lock_conflict on version mismatch with retry guidance;
GET /v1/accounts/{id}/balance -> { balance_minor, currency_code, version };
emits balance.updated event;
idempotent via external_id.

balance transitions are implicit (no named states);
guard: every read-modify-write acquires explicit lock or checks version;
no balance_minor update without SERIALIZABLE isolation;
deadlock triggers bounded retry with backoff.