circumference-pie asked:
A very very minor thing I have been curious about for a while, and I'm finally asking: why do you calculate queue posting times the way you do? For example, if I set my queue to post 3x a day, naively I would expect it to post every 8 hours. But in reality it posts every 6 hours with a 12 hour gap between days. Why complicate the math like that?
Answer: Hello @circumference-pie!
Buckle up y’all, it’s story time again!
First: nobody who works at Tumblr right now was a part of the work of planning the default queue implementation, which was more than ten years ago. So the full story behind “Why does it work that way?” has unfortunately been lost to the sands of time. All we can do is tell you how it works today and surmise some reasons why. The queue is actually a very clever system and part of how it works explains some of why it works the way it does. Also, there have been attempts to do what you ask—we still have “Queue 2.0” available in your Tumblr Labs settings, which tries to get closer to how you expect things to work.
Anyway! How the queue works today is not actually a queue in the traditional sense. There is no single list of posts that are in “your queue”. Instead, when you “Add to queue” after creating a post, we’re actually scheduling it to post at a future time, as if you had used the “Schedule post” option instead. We’re just calculating that time on your behalf when you use “Add to queue”, based on your settings, and how many other scheduled posts you have already. We use a secondary “index” model, called “ScheduledPost”, to keep track of posts you have scheduled on your blog. We do mark the ones that are a part of “your queue”, but the data model doesn’t keep one list of your “queue” per se.
You can see this in action on your blog, hiding in plain sight. If you add a bunch of posts to your queue, and then schedule a post for a specific future date, you’ll see both in your blog’s “queue” list, side by side. Because technically to us, they’re the same thing: queued posts are really just another kind of scheduled post, relying on the same always-running service to publish scheduled posts across all of Tumblr. Here’s a fun fact: we typically have about ~14.5 million future posts to publish from this list at any given time and are publishing hundreds of these scheduled posts every second.
So when you’re adding a new post to your queue, what we’re doing behind the scenes is starting at the beginning of your “day”, and creating time slots based on your queue settings. If a time slot is already filled, we move on to the next one. That’s why the default queue scheduler works how you describe—we’re trying to fill those “slots” based on the start of the day, rather than trying to divide the calendar day evenly. This just makes it much simpler for us to understand, scale, and predict when our “peaks” will be. At peak times, the publish-scheduled-posts service is publishing tens of thousands of posts in a manner of seconds. We did rewrite that post-publishing part of this architecture a few years ago to improve its efficiency and solve a lot of “lost post” bugs, but we didn’t change how “Add to queue” works.
However, the Queue 2.0 project available in Labs was an attempt to change the queue system to work as you expect—instead of starting at [beginning of day] and creating enough slots to fit [number of slots] every [number of hours], it tries to divide the calendar day into [number of slots] and fit the result back to the original algorithm’s mapping of the day. We never productionized this alternative approach, because it has a few bugs that some blogs hit in extreme cases, and we’ve never had time to fully fix them. It also can cause a bit of weirdness when time zones diverge, like with daylight savings time. Also, a lot of people prefer the default algorithm, and we haven’t thought of a nice way to transition everyone from one to the other. So for now, both options exist, and you can choose which algorithm for queue-slot-generating you want to use. We hope that makes sense!
While complicated, it is a great example of a system built by engineers to make sense and be scalable and predictable. But sometimes these kinds of systems, while clever, aren’t very intuitive to understand without digging into how they work.
Thanks for your question, and keep ’em coming.
