Fix concurrency double‑spend bug in simplebank transfer logic (Go + Postgres)
Budget: $10 – $15 USD
I have a finished simplebank project (Go backend with Postgres) that implements accounts, transfers, and basic transaction logic. I intentionally introduced a subtle concurrency bug related to money transfers and now want someone to debug and fix it.The problem happens when two or more transfers from the same source account run at the same time. Under concurrent load, the system sometimes allows the account to spend more money than it actually has (double‑spend). With normal, single requests everything appears to work fine: balance checks pass, transfers look correct, and the UI/API responses are OK. The bug only shows up with concurrent requests.
1. Expected behavior:
• Balance checks should be safe even under concurrency.
• If an account has a balance of 100 and two transfers of 70 run at the same time, at most one should succeed and the final balance must never go below 0 (or below the minimum allowed).
2. Actual behavior:
• If an account has a balance of 100 and two transfers of 70 are sent at the same time , sometimes both transfers succeed.
• The final balance can become negative or lower than it should be, meaning the account has effectively spent more than its real balance.
4. Suspected cause (on purpose):
The account read during transfer likely isn’t properly locked for update, allowing two transactions to see the same old balance and both commit.
What I need from you:
• Reproduce the issue with concurrent transfers (you can use tests, goroutines, or a simple load script).
• Find and fix the concurrency bug so that:
• Balance checks are safe under concurrent requests.
• Double‑spends are no longer possible.
• Update or add tests to verify this behavior under concurrency.
To apply:
- Include your experience.
- Timeline.
- Similar project.
1. Expected behavior:
• Balance checks should be safe even under concurrency.
• If an account has a balance of 100 and two transfers of 70 run at the same time, at most one should succeed and the final balance must never go below 0 (or below the minimum allowed).
2. Actual behavior:
• If an account has a balance of 100 and two transfers of 70 are sent at the same time , sometimes both transfers succeed.
• The final balance can become negative or lower than it should be, meaning the account has effectively spent more than its real balance.
4. Suspected cause (on purpose):
The account read during transfer likely isn’t properly locked for update, allowing two transactions to see the same old balance and both commit.
What I need from you:
• Reproduce the issue with concurrent transfers (you can use tests, goroutines, or a simple load script).
• Find and fix the concurrency bug so that:
• Balance checks are safe under concurrent requests.
• Double‑spends are no longer possible.
• Update or add tests to verify this behavior under concurrency.
To apply:
- Include your experience.
- Timeline.
- Similar project.