Component Event Vs Application Event in Lightening

Please refer below link for better understanding of events in Lightening

http://reidcarlberg.github.io/lightning-newbie/events.html

When using Future calls in Apex in Salesforce

1) A future call cannot make another future call and a future call cannot be made from a batch job.
With this limitation you have to be very careful in your code that a future call is not made from within a future call. This can be very easy if the code is short or you are doing a simple web service call as described above. But if you have a complex set of triggers or workflow rules in an organization it may not be that simple.
2) Future calls cannot be guaranteed to run in a certain order.
Just because one future call was made before another future call does not mean that the first one will complete first. There are multiple queues that are running these future calls so the order cannot be guaranteed. So if you need to guarantee that actions complete in a certain order then a batch or scheduled job may be the better solution.
3) Future calls can run concurrently.

It is possible that two future methods that were executed one after the other could basically run concurrently. This means you may have to deal with record locking if these two methods could be updating the same record. This may force you to use the ‘For Update’ method on your SOQL queries, which can be difficult to troubleshoot.
4) Future calls have limits

Salesforce has limits on how many future calls can be made so they cannot be used just anywhere. There is a limit of 10 future calls per Apex invocation. There is also the limit of future calls in a 24 hour period, which is 250,000 or the number of user licenses in your organization multiplied by 200, whichever is greater. Here is a link to those limits.
Future calls have their place to solve very specific use cases. But as Salesforce developers we have to be very careful in how we use them or we will end up with code that is difficult to debug and hard to manage.

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.