Increment/Decrement on High Traffic

it causes a problem it needs to wait before it updates because of the atomic lock

I don't think that there is another way than waiting ...

Stop running increment() or decrement() during the HTTP request. Dispatch a job (e.g., UpdateMerchantBalance). The API responds immediately, and your queue workers deal with the lock waiting in the background. The workers will still wait on each other for that specific row, but your web server won't hang and the user won't experience timeouts.

@eskiesirius You shouldn’t be using a single column to hold the balance. You should instead of some form of ledger table, where you write individual increments and decrements as their own rows, and then derive the balance from the sum of those increments and decrements. It’s not “expensive” if you have a proper index in place.

You can combine two logic to get the perfect route of what you want to achieve

1. Wallets Table Should look like this (in my own flow, not compulsory you do the same but it is what works for me)

wallets
- id
- user_id
- available_balance
- pending_balance
- version
- updated_at

Purpose:

1. fast balance reads

2. authorization checks

3. dashboard/API responses

4. Ledger Table

This is the accounting layer.

wallet_ledger
- id
- wallet_id
- reference
- transaction_type
- direction
- amount
- balance_before
- balance_after
- status
- created_at

Immutable

Never:

UPDATE ledger rows DELETE ledger rows

Corrections must be reversal entries.

This gives:

1. auditability

2. reconciliation

3. forensic traceability

4. Every Financial Operation Must Be ACID

Example debit flow

DB::transaction(function () {

    $wallet = Wallet::where('id', $walletId)
        ->lockForUpdate()
        ->first();

    if ($wallet->available_balance < $amount) {
        throw new Exception('Insufficient funds');
    }

    $before = $wallet->available_balance;
    $after = $before - $amount;

    WalletLedger::create([
        'wallet_id' => $wallet->id,
        'reference' => Str::uuid(),
        'transaction_type' => 'transfer',
        'direction' => 'debit',
        'amount' => $amount,
        'balance_before' => $before,
        'balance_after' => $after,
        'status' => 'completed',
    ]);

    $wallet->update([
        'available_balance' => $after
    ]);
});

Instead of:

balance = truth

you now have

ledger = truth
balance = optimized projection

This means:

if cache fails → safe if snapshot corrupts → rebuildable if Redis dies → safe if worker crashes → safe

Because the ledger remains authoritative.