[eluser]WanWizard[/eluser]
For these kind of processes I use a message queue.
For example, my forum code has the option to send a new post to you via email, or send you a notification that there's a new post. When a user posts a new message, it inserts a new record into the message queue for every user that needs to receive something, with a task_id (in this case send out a notification or a message), a priority, a timestamp, and any key information the message processor needs. This has little impact to the application in terms of performance.
In the background, a scheduled queue processor (a CI controller) is started by cron. It fetches the first message (the oldest or the one with the higest priority), checks the task_id, then calls the method liked to that id to process the record. When finished the queue message is marked as processed (or deleted, depending on a config setting), and the controller ends.
To control update access to the controller, I use a semaphore system using a file, to make sure only one process can fetch a queue record at the time. I don't want to use database locking mechanisms, to prevent a possible performance impact on the application.
Depending on the load (i.e. the frequency of new records in the message queue), one or more concurrent message processors are started.
Currently, this is home-grown code, and not to scalable. I've got a conversion to beanstalkd (including CI library) on the todo list to solve that problem.