Salesforce Queueable , Batch job and Future Methods

1.The Batchable Interface
 • When should you use it? -
Complex long running processes (thousands of records)
- Asynchronous processing - Scheduled jobs
• How can you define a Batch? - Implement Database.Batchable -
Define start(), execute() and finish() methods

The Batchable Interface
• Advantages -
It can process up to 50m records
It can be scheduled to run at a particular time
• Disadvantages - Only five concurrent batch jobs running at a time* - It’s difficult to troubleshoot - Execution may be delayed based on server availability -
@future methods are not allowed - Can’t use getContent/getContentAsPDF methods - and a few more governor limits…

2. @future method •
When should I use it?
 - When it’s not a batch (group = 2 or more) - Asynchronous processing (simple and often)
- Long-running operations (callouts to external web services) - Separating mixed DML operations
• How can I define @future method?
 - @future annotation - Must be static and return void - Specify (callout=true) to allow callouts
@future method
• Advantages - Asynchronous processing without a concurrent limit (queue)
- Easier and quicker to implement as opposed to Batch
- Can use getContent/getContentAsPDF methods
• Disadvantages - Parameters passed in can be only of Primitive type
 - - Can’t chain @future methods - Difficult access to job ID

3. The Queueable Interface
 • When should I use it?
 - When Batch and @future need to meet in the middle - Chaining jobs
 - You need @future method with support for non-primitive types
 - Asynchronous monitoring
 • How can I define Queueable Apex?
- Implement the Queueable interface - Define execute() method
• How can I enqueue a job? - ID jobID = System.enqueueJob(new MyQueueableClass());
The Queueable Interface • Advantages
 - Asynchronous processing with non-primitive arguments
- Easy access to the job ID - Chaining jobs* •
 Disadvantages - Can’t have more than one job in the chain that does callouts

Which one to use? Batchable @future Queueable
 - Good at processing large number of records (50m) and tasks are not time-crucial

 - Can be scheduled to run at a certain time 

- Maximum of 5 concurrent jobs running at a time 

- You need good error handling for troubleshooting 

- Quick async processing (typically one record at a time) e.g. avoid mixed DML or a web service callout - Faster than a Batch - Easy to implement

 - Only accepts primitive type arguments - Can’t chain jobs 

- Hard to monitor

 - Quick async processing that supports primitive types 

- Faster than a batch

 - Ability to chain jobs - Can’t have more than one job doing callouts within the chain - Can be monitored


Please accept my solution as Best Answer if my reply was helpful. It will make it available for other as the proper solution. If you felt I went above and beyond, you can give me kudos.

Thanks and Regards
Prateek