Clojurians Log v2

Could someone who read Designing Data-Intensive Applications help me understand this paragraph on page 523? > If you want to ensure that the payer account is not overdrawn by this transfer, you can additionally have a stream processor (partitioned by payer account number) that maintains account balances and validates transactions. Only valid transactions would then be placed in the request log in step 1. The author unfortunately doesn’t provide further description of how would this be implemented. I don’t understand how we can avoid a race condition between this stream processor consuming the log with committed requests to update the account balances and validating new transactions.

It will be a synchronous flow for the processing of transactions for a specific account since it's partitioned by account-id. There will be no race conditions for an account

> 1. The request to transfer money from account A to account B is given a unique request ID by the client, and appended to a log partition based on the request ID. So instead the request would go first to a partition based on the payer account number where it would be synchronously validated. If valid the stream processor would first update the payer account balance (used for validation only) and if that succeeds write the request to the request log?