Certain operations in eZ Publish/Platform takes a long time and should be handled by a asynchronous solution.

Some of these operations are currently not covered because of this component not being implemented yet, and others are implemented synchronous meaning they can risk timing out or even crashing if the database is to big.

This might imply some API changes to reflect that these don't return result directly (see CQRS/ES for inspiration), they become Commands, while others are ok as is.

Some identified cases:

• Subtree operations (move, delete, un-assign, trash, hide/unhide, ..)
• Search indexing on mass operations (all above + content type changes, section subtree assignments, ..)
• Cache clearing (SPI cache for more intelligent cache clearing there, HTTP cache should ideally not need this if we can add support for multi tagging the cache)

Role changes is also a case, but this one is far more complex then the once above, and might have to imply expiring (not purging) all HttpCache for instance.

Technically from a user perspective

(feel free to ignore this section as it might end up being irrelevant)
Looking to JIRA and how it deals with batch operations; it redirects the user to a batch updating screen where you can follow the progress.
So if we aim for something like that it would be:

1. API returning an operation/event object with information to be able to poll API for progress, typically used by UI to show progress
2. Async Events will need to support the following when they are taken out of the que to start the operation:
   1. Be able to tell how many items are affected by the change (roughly, count may change during the operation if it is a long running one)
   2. On each batch of x amount items, signal that it is done before taking next amount

Note: Open question regarding parallelism of events, and also 2.2. on parallel batches