Different types of asynchronous operations are not mutually exclusive. Can someone explain me briefly with some set of example?
closed as unclear what you're asking by battery.cord, Jayant Das, Reshma, Oleksandr Berehovskyi, Pranay Jaiswal Jan 24 at 10:26
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
The three types, batchable, future, and queueable, were designed based on customer requests and feedback. They did not all come out in a single release. While they may seem to not be mutually exclusive, that's because they really are not: they were designed in several iterations based on customer requests and feedback. Understanding the history behind these three features should make more sense as to why we even have three different types.
Batchable was the first, and came from requests for a way to handle millions of records in Apex. It was engineered to be efficient with large amounts of data in ways that were impossible at the time. However, you couldn't use batchable in a trigger because of the low limits, which made certain use cases impossible, such as making a callout from a trigger.
Future methods were released next, and designed based on feedback about batchable and the limitations thereof. They stripped out everything they could to make a lightweight "batch" designed for use in triggers. It was a little too lightweight, though, and wasn't suitable for situations where you needed to know if the code succeeded (e.g. called from a Visualforce page), and the limitation on data types were frustrating.
Finally, Queueable emerged as a compromise between the first two types. All three types now exist, but are generally separated by their use case. Batchable is suited for a few large updates at once, Queueable is suited for use in triggers, Visualforce, Lightning, etc. Future methods are technically obsolete compared to Queueable, but will still be supported for some time, since there's a lot of code that relies on it, and it doesn't make sense to take it out anyways, since it's already built.