This strategy is stated perfectly by Flickr's Myles Grant: The Flickr engineering team is obsessed with making pages load as quickly as possible. To that end, we’re refactoring large amounts of our code to do only the essential work up front, and rely on our queueing system to do the rest. Flickr uses a queuing system to process 11 million tasks a day. Leslie Michael Orchard also does a great job explaining the queuing meme in his excellent post Queue everything and delight everyone.
The process:
Identify the minimum feedback the client (UI, API) needs to know an operation succeeded. It's enough, for example, to update a client's view when a posting a message to a microblogging service. The client probably isn't aware of all the other steps that happen when a message is added and doesn't really care when they happen as long as the obvious cases happen in an appropariate period of time.
Queue all work not on the critical path to a job queueing system so the critical path remains unblocked. Work is then load balanced across a cluster and completed as resources permit. The more sharded your architecture is the more work can be done in parallel which minimizes total throughput time.
This approach makes it much easier to bound response latencies as features scale.
Queues Give You Lots of New Knobs to Play With
Bookmark/Search this post with:
Recent comments
6 hours 13 min ago
1 day 7 hours ago
1 day 13 hours ago
2 days 4 hours ago
2 days 9 hours ago
2 days 17 hours ago
2 days 22 hours ago
3 days 10 hours ago
3 days 19 hours ago
4 days 2 min ago