Queueable VS @future

This article is going to compare the @future and Queueable Interface.

@future Methods:
A future method runs asynchronously. And its governor limits are higher:

Description	Synchronous Limit	Asynchronous Limit
Total number of SOQL queries	100	200
Total heap size	6MB	12MB
Maximum CPU time	10,000 milliseconds	60,000 milliseconds

When to use it:

1. Long-running operations (callouts to external web service)
2. Separating mixed DML operations (i.e. inserting a user with a non-role must be done in a separate thread from DML operations on other sObjects)

How to define it:

   Global class FutureClass{
         @Future(Callout=true)
             public static voidmyFutureMethod(){
                  // Perform your logic ...
             }
}

1. future anotation
2. Must be static and return void
3. Specify (callout=true) to allow callouts

Limits: 

1. Parameters passed in can be only of Primitive type
2. Cannot chain @future method
3. Cannot get the job ID

Queueable Interface:

This interface enables you to add jobs to the queue and monitor them which is an enhanced way of running your asynchronous Apex code compared to using future methods.
Like @future, a benefit of using the Queueable interface is that some governor limits are higher than synchronous Apex (see the table above).

When to use it comparing with @future:

1. Chaining jobs
2. Asynchronous monitoring (it gets job ID)
3. Using non-primitive types

Public class AsyncExecutionExample implements Quaueable ,Database.allowcallouts{
    Public void exccute (QuaueableContext context){
      // Perform your operation here ...
    }
}

Much like what we did on using batchable interface

1. Implement the Queueable interface
2. Define execute() method
3. Chain this job to next job by submitting the next job
4. Implement the Database.AllowsCallouts interface to allow callouts

Limits:

1. When chaining jobs, you can add only one job from an executing job with System.enqueueJob.
2. Cannot have more than 1 job in the chain that does callouts.