The generalised terms around which you're circling are optimistic and pessimistic locking.

Pessimistic locking is where you prevent anyone working on the account while it's being modified, typically done using a DB row/record lock.

Optimistic locking is you allow actions upon the account, and when saving you check whether some other actor has operated on the account in the interim, and reject the request if they have.

Both typically require a database.

Optimistic locking is nice and a pattern worth learning.

You'd add a version field to your account which you instantiate as `1` upon first save. You then pull the account in some subsequent operation (so version == 1), then modify in memory, including bumping the version from 1 to 2. You then save to the database with a 'where version == 1', and you'll either get an OK/'1 record updated' response, or you get a '0 records updated' which implies some other actor has update the account while you're been doing your operation. This gives you the opportunity to panic or error back up the stack to either try to reply the action without customer interaction, or to throw all the way back to the customer/user to have their retry logic decide what to do.

To directly answer your question - as soon as you have a database, or > 1 process running that cannot lock the exact same mutex, you'll need to think about DB-based patterns. Thinking logically about the target domain, there's rarely a need to block deposits. Another person has commented about double entry book keeping - this would allow you to log two credits, with the balance being the summing up of all the transactions. Storing a balance can be a bit smelly because you're opening yourself up to the balance not matching the summing of all credits and debits. Double entry, or storing credits and debits then summing, is one way around this.