As soon as as a user types that into the browser, a few things will happen of course at that exact moment an http request is received by ________. and then it

As soon as as a user types that into the browser, a few things will happen of course at that exact moment an http request is received by ________. and then it will call iron.io ironmq or something like that, put in a request to the queue, fire off some ffmpeg scripts in the ironworker asynchronously, receive message that it's successful, send back to the browser animated gif that has been rendered. During this time, the user will just have to wait, until the task completes. I'm not sure if I would want them to time out because what if (edge case), someone decides to convert one of those "Nyan cat loop for 10 hours" videos, the server is stuck in a long task. Then comes the question of whether the same long process will continue if some other user wants to test out this exploit. That's where I think persistent storage of the processed file would come in handy. the request url should first be scanned if it's existing in one of our previous url requests. Redis could be used replacing rabbitmq or ironmq. but I'm think for spike cases, not in a sense that the app will become hugely popular overnight (although making it on the first page of news ycombinator would awesome), but certain users either being passionate users making lot of requests and malicious individuals abusing it. I really don't want to block the api behind the http auth dialog or a web based login. I envision it to just work like you would use google, except you can convert youtube videos to animated gifs, just by entering in the url. Of course in the backend, I'd need extensive monitoring and realtime analytics would be cool.