To expand the image resizing example:
Most web gallery requests go like: (ignoring caching)
Browser -> PHP -> Database
When you upload an image you could simply handle it in-line in the server:
Browser -> PHP -> DB -> Resizer
That means the next page refresh is waiting on that resizer to finish which means long page latency to the most latency-sensitive component imaginable (the fickle user).
So you really want that resize to happen asynchronously, i.e. not wait for the result before showing the page. The roll-your-own method is to put a row in the DB that says "Hey I need to be resized" and have a cron job or somesuch that does the resizing:
Browser -> PHP -> DB
Resizer -> DB
This of course puts all the load on the hardest thing to scale (the DB) so you grow out of it fast. Hence message queues. RabbitMQ, ActiveMQ, Redis, etc are all variants of the queue, so now you have:
Browser -> PHP -> DB -> Queue
And the Queue holds all the resizing jobs that need to be done. You could just modify your cronjob to check the Queue instead of the DB of course.
Octobot (and Celery) is a queue runner that connects to that Queue, reads in the jobs that need to be done and runs them. So instead of a cron job you write your resizer in a way that your queue runner understands and the runner will manage some of the plumbing for you.
So you have
Browser -> PHP -> DB -> Queue
Queue -> Octobot -> Resizer ( -> DB to say it's done perhaps.)
Now that you're decoupled you can add more resizers, webservers, distribute them across multiple systems, expand to EC2 to handle overflow load, etc by leveraging what your queue provides.
