Introduction
After years of filling out forms and waiting, you've finally acquired your banking license.
This means you are now officially eligible to open your own bank, hurray!
Your first priority is to get the IT systems up and running.
After a day of hard work, you can already open and close accounts, as well as handle withdrawals and deposits.
Since you couldn't be bothered writing tests, you invite some friends to help test the system.
However, after just five minutes, one of your friends claims they've lost money!
While you're confident your code is bug-free, you start looking through the logs to investigate.
Ah yes, just as you suspected, your friend is at fault!
They shared their test credentials with another friend, and together they conspired to make deposits and withdrawals from the same account in parallel.
Who would do such a thing?
While you argue that it's physically impossible for someone to access their account in parallel, your friend smugly notifies you that the banking rules require you to support this.
Thus, no parallel banking support, no go-live signal.
Sighing, you create a mental note to work on this tomorrow.
This will set your launch date back at least one more day, but well...
Instructions
Your task is to implement bank accounts supporting opening/closing, withdrawals, and deposits of money.
As bank accounts can be accessed in many different ways (internet, mobile phones, automatic charges), your bank software must allow accounts to be safely accessed from multiple threads/processes (terminology depends on your programming language) in parallel.
For example, there may be many deposits and withdrawals occurring in parallel; you need to ensure there are no race conditions between when you read the account balance and set the new balance.
It should be possible to close an account; operations against a closed account must fail.
Roc/Host responsibilities
In Roc code, we typically focus on the business logic while the platform handles concurrency and shared state.
Therefore, in this exercise you only need to implement the account operations in BankAccount.roc without having to worry about concurrency.
Accounts start closed, reopening resets the balance, and deposits and withdrawals must be positive.
Optional server demo
The included bank-account-demo.roc shows how your implementation can be used in a small web service.
You can read it in the editor, but it is independent of the tests and is not part of your solution.
To run the demo, you must install Roc on your machine, install the Exercism CLI, then run this command in a terminal:
exercism download --exercise=bank-account --track=roc
Next, implement BankAccount.roc and test it with the following command (change the download location printed by the CLI if it differs from the path below):
cd ~/Exercism/roc/bank-account
roc test bank-account-test.roc
Once all the tests pass, you can start the demo server with the following command:
roc bank-account-demo.roc
The server uses the basic-webserver platform and its built-in SQLite support (Roc downloads the platform on the first run).
No separate database server is needed.
The server listens on http://127.0.0.1:8000 and creates bank-account-demo.db in your current directory (set DB_PATH to use a different database file).
Stop the server with Ctrl-C.
The data survives restarts.
In another terminal, you can call the webservice using curl (on Windows, use curl.exe throughout to avoid PowerShell's curl alias).
For example, here is how to open account #123, deposit 50, withdraw 10, and check its balance:
curl -X POST http://127.0.0.1:8000/accounts/123/open
curl -X POST http://127.0.0.1:8000/accounts/123/deposit/50
curl -X POST http://127.0.0.1:8000/accounts/123/withdraw/10
curl http://127.0.0.1:8000/accounts/123/balance
The balance is 40.
Account IDs and amounts must be unsigned integers.
Updates return OK on success or an error from your account implementation on failure.
To close account #123:
curl -X POST http://127.0.0.1:8000/accounts/123/close
To try concurrent requests on Linux/macOS, use a fresh account ID and send 100 deposits from eight clients:
curl -X POST http://127.0.0.1:8000/accounts/456/open
seq 100 | xargs -P 8 -I '{}' curl --fail --silent --show-error -X POST http://127.0.0.1:8000/accounts/456/deposit/1
curl http://127.0.0.1:8000/accounts/456/balance
On Windows, use PowerShell 7+ for the parallel example:
curl.exe -X POST http://127.0.0.1:8000/accounts/456/open
1..100 | ForEach-Object -Parallel { curl.exe --fail --silent --show-error -X POST http://127.0.0.1:8000/accounts/456/deposit/1 } -ThrottleLimit 8
curl.exe http://127.0.0.1:8000/accounts/456/balance
The deposits should all succeed and the balance should be 100.
How the demo handles concurrency
Each request reads the account, calls your Roc functions, and saves the result within an SQLite Immediate transaction.
Failed operations roll back without changing the account.
SQLite allows one writer at a time, preventing concurrent requests from overwriting each other's updates (even across different accounts).
Note: The exercise uses U64, but the demo stores balances as SQLite integers and rejects updates exceeding the maximum I64 value (9223372036854775807).
For an example of running independent computations in parallel, try the parallel-letter-frequency exercise.
Hints
Show hints
Use match to distinguish Closed from Open(balance).
An operation returns an updated account rather than modifying the account passed to it.
Use Ok(updated_account) for a successful update and Err(...) for a rejected operation.
