🧵 Async Apex Unleashed: @future, Queueable, and Batchable with Real Patterns

Whats this Async you speak off

👀 You know that moment… You’re building a powerful LWC or a Flow-powered approval engine. Everything looks clean — until one save operation triggers 7 updates, 2 callouts, and maybe even a data sync to another org. Boom — limits hit, errors logged, admins confused.

That’s when you realize: You need async Apex.

🧠 My Learning Strategy: Stay Curious, Stay Sharp

Before we dive in — here’s how I learn anything deeply and permanently.

💡 I ask 5 simple questions:

• What is [concept]?
• When would you use it?
• Where would you use it?
• Why would you use it?
• How would you use it?

This forces me to live in the discovery phase of learning — not just absorbing answers, but asking better questions. It sharpens critical thinking, builds context, and makes the knowledge actionable.

🔍 What are @future, Queueable, and Batchable?

These are Salesforce’s async superheroes — each with a job:

✅ When would you use them?

Use async Apex when:

• You’re making callouts from a trigger or after DML
• Need to avoid hitting SOQL/DML governor limits
• Processing massive data sets
• Want to defer, chain, or scale logic
• Breaking heavy logic into modular jobs

higher

🌍 Where would you use them?

• Triggers offloading post-DML logic
• LWC or Flow → Apex → Queueable chain
• Scheduled jobs and background cleanup
• API integrations or post-callout workflows
• Data-intensive batch reports

💡 Why would you use them?

✅ Protect against limits ✅ Improve user experience ✅ Scale up background processing ✅ Clean separation of concerns ✅ Retryable, debuggable logic

🛠️ How would you use them?

✅ Interface-first ✅ SOLID principles ✅ One instance per context ✅ Async logic lives outside the main transaction

🎯 Real-World Scenario: Booking Management System

After inserting new Booking__c records, we want to: ✅ Check vehicle availability (callout) ✅ Queue updates & notify managers ✅ Batch-process usage data

1️⃣ @future(callout=true) — Fire-and-Forget Callout

🔹 Interface

public interface IBookingCallout {
    void scheduleAvailabilityCheck(String bookingId);
}

🔹 Implementation

public class BookingCallout implements IBookingCallout {
    @future(callout=true)
    public static void scheduleAvailabilityCheck(String bookingId) {
        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:VehicleService/bookings/' + bookingId);
        req.setMethod('GET');
        HttpResponse res = new Http().send(req);
        System.debug(res.getBody());
    }

    public void scheduleAvailabilityCheck(String bookingId) {
        scheduleAvailabilityCheck(bookingId);
    }
}

2️⃣ Queueable — Chainable Background Logic

🔹 Interface

public interface IBookingQueueHandler {
    void enqueueBookingUpdate(Set<Id> bookingIds);
}

🔹 Implementation

public class BookingQueueHandler implements IBookingQueueHandler {
    public void enqueueBookingUpdate(Set<Id> bookingIds) {
        System.enqueueJob(new BookingQueueJob(bookingIds));
    }
}

public class BookingQueueJob implements Queueable {
    private final Set<Id> bookingIds;

    public BookingQueueJob(Set<Id> bookingIds) {
        this.bookingIds = bookingIds;
    }

    public void execute(QueueableContext context) {
        List<Booking__c> updates = [SELECT Id, Status__c FROM Booking__c WHERE Id IN :bookingIds];
        for (Booking__c b : updates) {
            b.Status__c = 'Queued';
        }
        update updates;
    }
}

3️⃣ Batchable — Mass Fleet Processing

🔹 Interface

public interface IFleetBatchRunner {
    void runFleetUsageBatch();
}

🔹 Implementation

public class FleetUsageBatchRunner implements IFleetBatchRunner {
    public void runFleetUsageBatch() {
        Database.executeBatch(new FleetUsageBatch(), 200);
    }
}

public class FleetUsageBatch implements Database.Batchable<SObject> {
    public Database.QueryLocator start(Database.BatchableContext context) {
        return Database.getQueryLocator([SELECT Id FROM Fleet__c]);
    }

    public void execute(Database.BatchableContext context, List<SObject> scope) {
        List<Fleet__c> fleetRecords = (List<Fleet__c>) scope;
        for (Fleet__c f : fleetRecords) {
            f.Usage_Status__c = 'Processed';
        }
        update fleetRecords;
    }

    public void finish(Database.BatchableContext context) {
        System.debug('Fleet usage report done.');
    }
}

[embed]

🧪 Test It Like You Mean It

@isTest
public class BookingQueueTest {
    @isTest static void testQueueLogic() {
        List<Booking__c> bList = [SELECT Id FROM Booking__c LIMIT 2];
        new BookingQueueHandler().enqueueBookingUpdate(new Map<Id, Booking__c>(bList).keySet());

        Test.startTest();
        System.enqueueJob(new BookingQueueJob(new Map<Id, Booking__c>(bList).keySet()));
        Test.stopTest();
        // Assert logic
    }
}

🧠 Bonus: Async Apex in a Real-World Orchestration Pattern

Imagine this in a real trigger or Flow-powered framework:

• 🔥 Trigger inserts a Booking__c → delegates to service
• 🔁 Service:

1.Triggers @future callout

2.Enqueues Queueable for post-save actions

3.Nightly scheduled class kicks off Batchable for reporting

🎯 Each task is isolated, reusable, testable. ⚙️ Easy to extend. 🧪 Safe to mock.

✅ SOLID Design Highlights

🔚 Conclusion

Async Apex isn’t optional anymore — it’s how you build scalable, limit-safe systems in Salesforce.

When your app hits governor walls, or your integrations get complex — don’t hack your way out. Design your way out with @future, Queueable, and Batchable.

Just remember: ✅ One class per task ✅ Interface it ✅ Mock it ✅ Test it ✅ Scale it

Because true architects don’t fear async. They orchestrate it. 🎼🧵 — The SalesforceKlever way