I wrote an article about how you can use some form of in-database tracking state (identifying what needs to be done), Platform Events and a Platform event subscriber to take processing "async" from triggers in a governor friendly manner.

By using Platform Events you actually avoid using daily async limits and instead use from your hourly Platform Event publication limits (which are relatively high). Of course, to do an actual callout you do (sadly) still have to use async.

Note that Apex trigger-based Platform Event subscribers have the characteristic that they are called in a single-threaded manner.

You will find example code attached to the article, which flags the actual records themselves (though does not then go async as needed for a callout) and a second example that does.

I wrote an article about how you can use some form of in-database tracking state (identifying what needs to be done), Platform Events and a Platform event subscriber to take processing "async" from triggers in a governor friendly manner.

By using Platform Events you actually avoid using daily async limits and instead use from your hourly Platform Event publication limits (which are relatively high). Of course, to do an actual callout you do (sadly) still have to use async.

Note that Apex trigger-based Platform Event subscribers have the characteristic that they are called in a single-threaded manner.

You will find example code attached to the article, which flags the actual records themselves (though does not then go async as needed for a callout) and a second example that uses a separate "command" object to track what must be done (and includes bulkified async for simulated callout support).