Enforce Governor-Limit-Safe Batch Processing

global class RecalculateBalancesBatch implements Database.Batchable<SObject> {
    global Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator([SELECT Id, Balance__c FROM Bank_Account__c]);
    }

    global void execute(Database.BatchableContext bc, List<Bank_Account__c> scope) {
        Map<Id, Decimal> sums = new Map<Id, Decimal>();
        for (AggregateResult ar : [
            SELECT Bank_Account__c acc, SUM(Amount__c) total
            FROM Transaction__c
            WHERE Bank_Account__c IN :scope AND Type__c = 'Deposit'
            GROUP BY Bank_Account__c
        ]) {
            sums.put((Id) ar.get('acc'), (Decimal) ar.get('total'));
        }
        // (a full solution also subtracts withdrawal sums per account)

        for (Bank_Account__c acc : scope) {
            acc.Balance__c = sums.containsKey(acc.Id) ? sums.get(acc.Id) : 0;
        }
        update scope;
    }

    global void finish(Database.BatchableContext bc) {}
}

1. global class RecalculateBalancesBatch implements Database.Batchable<SObject> { — the class, implementing the required interface.
2. global Database.QueryLocator start(Database.BatchableContext bc) { — defines what to process.
3. return Database.getQueryLocator([SELECT Id, Balance__c FROM Bank_Account__c]); — every account, potentially thousands.
4. } — closes start.
5. (blank line)
6. global void execute(Database.BatchableContext bc, List<Bank_Account__c> scope) { — runs once per chunk of accounts.
7. Map<Id, Decimal> sums = new Map<Id, Decimal>(); — accumulates a fresh sum per account, ignoring any stored value.
8. for (AggregateResult ar : [ — Module 20's aggregate SOQL.
9. SELECT Bank_Account__c acc, SUM(Amount__c) total — groups and sums in the query itself.
10. FROM Transaction__c — the underlying object.
11. WHERE Bank_Account__c IN :scope AND Type__c = 'Deposit' — scoped to this chunk's accounts, deposits only.
12. GROUP BY Bank_Account__c — one row per account.
13. ]) { — closes the query, opens the loop over its results.
14. sums.put((Id) ar.get('acc'), (Decimal) ar.get('total')); — stores each account's freshly summed total.
15. } — closes the for loop.
16. // (a full solution also subtracts withdrawal sums per account) — a noted simplification.
17. (blank line)
18. for (Bank_Account__c acc : scope) { — iterates every account in this chunk.
19. acc.Balance__c = sums.containsKey(acc.Id) ? sums.get(acc.Id) : 0; — overwrites the stored balance with the freshly recalculated one.
20. } — closes the for loop.
21. update scope; — one DML statement per chunk.
22. } — closes execute.
23. (blank line)
24. global void finish(Database.BatchableContext bc) {} — no closing work needed here.
25. } — closes the class.

Even a well-tested trigger (Module 31) can drift from correct over time — a bulk data-load bypassing the trigger, a bug fixed after some records were already affected, or a manual data correction. A periodic recalculation job, using Module 38's exact Database.Batchable shape, is a safety net that self-heals any such drift.

The start/execute/finish structure, the Database.QueryLocator for scale, and the default 200-record scope are identical to Module 38's Batch Apex lesson — a banking system doesn't need different batch mechanics, it needs the same reliable mechanics applied to a domain where "the numbers must be right" carries more weight than a typical rollup.

Database.executeBatch(new RecalculateBalancesBatch(), 50);

1. Database.executeBatch(new RecalculateBalancesBatch(), 50); — the second argument sets a smaller-than-default chunk size explicitly.

Passing 50 instead of the default 200 reduces the risk of any single batch's aggregate query hitting limits when an account has an unusually large transaction history — a deliberate, documented trade-off (slower overall job, safer per-batch execution) rather than an arbitrary number.