What Happens When You Click 'Publish'

You've written something you want to share with the world. It's sitting in your Jottings dashboard—maybe a quick thought, a link you found interesting, or a photo with some context. You hit the "Publish" button, and a second or two later, it appears on your public site. Simple, right?

Well, not quite. Behind that button is a surprisingly elegant chain of events that I find genuinely exciting. It's why I built Jottings this way. Let me walk you through what actually happens.

The Moment You Click

When you hit publish, your jot—the text, metadata, any images you've attached—gets saved to our database. That part is instant. Your dashboard shows the new post immediately. But getting it onto the internet, making it readable by search engines, syncing it to a blazing-fast CDN? That happens asynchronously, in the background. This is the secret sauce.

Instead of making you wait while all that happens, I send a message to an AWS SQS queue. SQS is like a mailbox for asynchronous work. Your publish request gets queued with a priority level, and our build system picks it up as soon as it's ready.

The Build Processor Wakes Up

On the other end, a Lambda function sits listening to that queue. When a new message arrives, it springs into action. This is the build processor—the real workhorse.

Here's what it does: It fetches your site from the database, pulls all your published jots, and starts generating static HTML files. For each jot, it:

  • Parses your markdown and converts it to beautiful, readable HTML
  • Generates meta tags for social media (Open Graph, Twitter Cards)
  • Creates feeds (RSS, JSON Feed) so people can subscribe to your thoughts
  • Builds a tag system if you've used tags—individual pages for each tag and a tag cloud
  • Handles pagination if you have a lot of posts

The output? A complete, static website. No database calls needed when someone visits. Just pure HTML, CSS, and JavaScript delivered instantly.

Static Files to the Edge

Once the HTML is generated, the build processor uploads everything to Cloudflare R2—a cloud storage service that integrates seamlessly with Cloudflare's global CDN. R2 is smart: it's cheaper than the alternatives, and it ties directly into Cloudflare's network that spans the planet.

Your site now lives at hundreds of edge locations around the world. When someone in Tokyo visits your site, they're getting served from a data center near them, not from a central server in Ohio or Virginia.

The CDN Makes It Fast

Here's the magic: when a visitor lands on your site, they're not hitting your server. They're hitting Cloudflare's edge network. If someone has already visited your site in the last hour, their browser request might be served from cache—meaning your content arrives in milliseconds.

Even on first visit, the physical proximity matters. A reader in Singapore gets your site from a server geographically near them, not from halfway around the world. It's simple physics, but the effect is real. Your site feels fast, and that matters.

Error Handling: When Things Go Wrong

Here's where the system gets really thoughtful. If the build processor hits an error—maybe there's invalid markdown in one of your posts, or a temporary network hiccup—the message doesn't just disappear. It gets routed to a dead-letter queue.

I can then investigate what went wrong, fix it, and requeue the build. You get notified about the issue, and we work together to resolve it. No silent failures. No content that should be live but isn't.

Why This Architecture?

You might wonder: why not just generate the HTML when you click publish and be done with it? Why add queues and background workers?

A few reasons:

Scalability: If 10 of you publish simultaneously, the system handles it gracefully. The queue manages the workload. That Lambda function scales horizontally—more requests just spin up more instances.

Reliability: Network blips don't affect your publish experience. You hit publish, you see it in your dashboard. The actual build happens reliably in the background.

Cost: Serverless is only cheap when you use it this way. You don't pay for a server sitting around waiting for publishes. You only pay when work actually happens, and you pay pennies.

Speed: Your dashboard doesn't wait. You get instant feedback that your post is published. The build happens in parallel while you're already back to writing your next thought.

The Whole Thing Takes Seconds

From the moment you hit publish to when your site is updated globally? Usually 5-15 seconds. Rarely longer than 30. For a completely rebuilt, static site distributed to a global CDN, that's kind of wild.

I've built this system to be invisible. You publish, and it just works. You don't need to think about queues or Lambda or CDN edge locations. Your thoughts should move from your mind to the internet frictionlessly.

But I think it's worth knowing what's happening behind the scenes. It's not magic—it's engineering. And good engineering feels like magic to the user.

Next time you publish something on Jottings, take a moment to appreciate that brief window between clicking the button and your post going live. A lot is happening in those seconds.


That's the journey your post takes. Simple from the outside, elegant on the inside. If you want to see this in action for yourself, you know what to do.