One of the problems I obsessed over early in building Jottings was this: What happens when everyone publishes at the same time?
It's not a theoretical problem. When you launch a feature, when a site goes viral, when morning hits and half your users are on coffee breaks publishing their thoughts—traffic spikes happen. And the last thing you want is to tell someone "sorry, your site will rebuild in 2 hours because we're backed up."
So I built a queue system with priorities. It sounds simple, but the thinking behind it is something I'm genuinely proud of.
The Problem with Fair Treatment
When I first designed Jottings, every build request went into a single queue, processed first-in-first-out. Fair, right? Everyone waits their turn.
Except it's not fair at all.
Imagine this scenario: A user publishes their first jot on Jottings. Their site needs to build for the first time. Meanwhile, someone else who published 10 seconds earlier is still in the queue. The new user waits behind them, even though their situation is fundamentally different.
Or worse: A site with 50,000 jots republishes everything (maybe they updated their design settings). That rebuild request jumps into the queue ahead of someone who just wants to add a single new jot.
FIFO works great for fair resource allocation. But it's terrible for user experience.
How Priority Queues Work
Instead of one queue, Jottings now has three:
High Priority — New sites and small updates. When you first create a site or add a single jot, your build jumps to the front of the line. This is intentional. First-time users should see their site live as quickly as possible. The psychological win of seeing your new site go live in 30 seconds instead of 5 minutes shapes how people feel about the platform.
Normal Priority — Regular rebuilds and standard updates. You're updating your site settings, republishing a few jots, or making normal changes. These go in the middle queue. Most of your builds will land here, and they still process quickly because the high-priority queue is smaller.
Low Priority — Large batch operations and full site regenerations. You're doing a design overhaul. You're bulk-importing 100 old blog posts. You're changing theme settings that affect every page. These are heavy operations. They're necessary, but they don't need to block everything else. They process when the other queues are clear or moving fast.
The beauty of this system is that it scales. If high-priority is empty, normal priority jobs start processing immediately. If high-priority is backed up, normal and low priority jobs still inch forward, so nothing stalls completely.
Why New Sites Get Priority
Here's where I made a decision I want to explain, because I think it reveals my philosophy about Jottings.
New sites get high priority.
Not because they're more important. Not because I made a mistake in the queue logic. But because the first experience matters more than the tenth experience.
When someone creates a site on Jottings, they're making a bet. They're saying "I think I'll actually use this." And I want that bet to pay off immediately. I want them to see their site live, see their domain working, see their jots in the wild—fast.
The fifty-first build for an existing user can wait 2 minutes if needed. But the first build for a new user should happen in under a minute, ideally under 30 seconds.
This is why startup founders obsess over onboarding. The first experience shapes everything that comes after.
What About Fairness?
I won't pretend this is perfectly fair. A heavy user with lots of sites gets lower priority on batch operations than a brand new user publishing their first jot.
But here's what I think: fairness isn't about treating everyone identically. It's about treating everyone the way their situation demands.
A brand new user needs speed to build confidence. An established user with 50,000 jots can wait an extra minute for a batch operation because they already trust the platform.
The system I built isn't egalitarian. It's proportional. It recognizes that different operations have different urgency, and it routes them accordingly.
How You Benefit
You probably don't think about the priority queue while you're using Jottings. That's the point.
What you do experience is:
- New site builds that feel instant
- Single jots that publish in seconds
- Site updates that don't cause huge delays for small changes
- Batch operations that happen in the background without disrupting your workflow
The queue is invisible infrastructure. But it's there, making sure that when you publish, your site is live quickly.
The Fairness Question
I get asked sometimes: doesn't this prioritization disadvantage power users?
My answer: no, it doesn't. Here's why.
If you're a power user, you're doing batch operations occasionally. Those go to low priority, but they're background work. You're not waiting for them in real-time. You kicked off the batch rebuild, and it happens while you sleep or while you're working on something else.
Your regular publishing—adding a new jot, updating a post—still goes through normal priority and stays fast.
The only person truly disadvantaged is someone running a massive batch operation during peak hours. And honestly? That person benefits from having a small, fast site to build while their batch cooks in the background.
It's a system that rewards the people using Jottings the way it's designed to be used: frequent, small updates that feel immediate.
Looking Forward
I'm monitoring the queues closely. If I see that high-priority is getting backed up during peak hours, I might adjust the distribution. If power users need faster batch operations, I could add a PRO feature for priority access.
But for now, this feels right.
A system that makes the first experience fast. That keeps regular publishing snappy. That handles bulk operations without crashing everything.
If you're curious about what your builds are actually doing—and I think you should be—you can always check your build logs in the Jottings dashboard. See when it queued, when it started, how long it took. That transparency helps me keep improving.
That's what I'm always trying to do: make an experience so invisible and reliable that you forget the infrastructure is even there.
Building a microblog should feel effortless. If you're curious about how Jottings handles the technical side so you can focus on your writing, try it free today.