Architecture for a Serverless Post Scheduler

Jan 22, 2025

In late December 2024, I started exploring the idea of building a tool to streamline posting and scheduling across social media platforms. This idea came from my personal experience using Bluesky alongside Twitter. While the platforms delivered similar content, I found myself gravitating toward Twitter because of my network there. The thought struck me: what if I could make it easier to manage content across multiple platforms at once?

After doing some market research, I realized that tools like this already exist, I decided to create Bizmo.Social—a social media management tool that would also integrate seamlessly with Bizmo.site, my existing platform for businesses. On December 22, 2024, I purchased the domain and began designing and building the architecture for the tool.

Here’s how I approached creating a scalable, serverless architecture for Bizmo.Social and the challenges I faced along the way.

Bizmo Social Architecture

Approach 1: Initial Architecture with AWS Lambda and EventBridge

To get started quickly, I chose a serverless architecture using AWS Lambda, Amazon EventBridge, and SQS (Simple Queue Service). The initial system worked like this:

  1. Post Scheduling:

    • Users would schedule posts, which were saved in a database.

  2. Triggering Events:

    • I used Amazon EventBridge to trigger events at the scheduled time.
    • These events would queue the post in SQS, which acted as a buffer between the trigger and the publishing process.

  3. Processing Posts:

    • AWS Lambda functions consumed the queue and published the post to the appropriate social media platforms.

This approach was simple and leveraged the scalability of serverless technologies. However, as I tested the system, I encountered significant limitations:

  • Editing Scheduled Posts: Once a post was queued, there was no straightforward way to edit it. If a user wanted to change the scheduled time or content, I had to delete the existing queue item and insert a new one.
  • Scheduling Flexibility: EventBridge was great for triggering events, but it wasn’t optimized for dynamic schedule changes. Adjusting post timings after they were scheduled became cumbersome.

While this setup worked as a proof of concept, it became clear that I needed a more flexible and maintainable solution.

OpenGraph image

Approach 2: Transitioning to a Cron Job Approach

To address the challenges of editing and rescheduling posts, I redesigned the architecture with a database-centric approach. Here’s how it worked:

  1. Centralized Scheduling Logic:

    • All scheduled posts were stored in a database, which acted as the single source of truth.
    • The database included fields for the post’s content, the scheduled time, and its current status (e.g., "pending" or "published").

  2. Cron Jobs for Scheduling:

    • I used Cloudflare Workers to set up a cron job that ran every minute.
    • The cron job queried the database for posts scheduled to go live in the current minute.

  3. Queue-Based Processing:

    • The cron job fetched the posts from the database and pushed them into a queue for processing.
    • Cloudflare Workers consumed the queue, processed each post, and published it to the respective social media platforms.

  4. Dynamic Edits:

    • Users could freely edit or reschedule posts in the database at any time before publishing.
    • Since the cron job fetched posts directly from the database, any changes made to a post were automatically reflected in the next cron cycle.

This new architecture solved the problems I faced with the initial design:

  • Flexibility: Users could edit or reschedule posts without needing to delete or replace queue items manually.
  • Simplicity: The cron job fetched the latest data directly from the database, eliminating the need to update queue items.
  • Scalability: The database-centric approach scaled well, as Cloudflare Workers efficiently handled high volumes of posts.

Approach 3: Alternative Approach with AWS EventBridge and Lambda

While the database-centric architecture was working well, my friend Sahil—a friend i met on twitter and a developer who had previously worked at Scalar, was visiting kochi and Naturally, I hosted him at my home, we had a nice coffee chat and Talk architecture, of course. I mean, what else would a beginner-enthusiast like me discuss with a senior dev over chai and snacks? Life? Politics? Nope. It was queues, databases, and cron jobs (and some weather , travel and life too).

The conversation went something like this: Sahil: “What is your architecture like for bizmo social.” Me: “I built a cron-job-based system with Cloudflare Workers to fetch posts from the database every minute!”
Sahil: “Hmm, that’s nice. But why not use AWS EventBridge for dynamic scheduling? It could eliminate the need for a cron job altogether.”

He then went into a detailed explanation, complete with hand gestures of how the EventBridge and Lambda combo could work. I nodded along, trying my best not to look like I was questioning my entire existence as a developer. But seriously, who else would take a perfectly fine architecture and immediately propose an alternative?

Here’s what Sahil’s alternative approach looked like:

  1. EventBridge for Scheduling:

    • Scheduled posts were stored in a database, similar to the database-centric approach.
    • Instead of relying on a cron job, posts were dynamically scheduled in AWS EventBridge based on their scheduled time.

  2. Dynamic Validation:

    • When an EventBridge trigger fired, it pushed a message to the queue for processing.
    • During processing, the system checked the database to validate the post’s scheduled time and content. If the database had been updated (e.g., if the post had been rescheduled or edited), the message was invalidated, and the updated post data was fetched.

  3. Processing Posts:

    • Similar to the previous approach, AWS Lambda functions consumed the queue and published the posts to the social media platforms.

This architecture offered an interesting trade-off:

  • Advantages:

    • EventBridge eliminated the need for a cron job, simplifying the scheduling logic.
    • Dynamic validation ensured that edits to posts were always reflected, even after the post was added to the queue.

  • Drawbacks:

    • EventBridge scheduling was less developer-friendly compared to the cron job approach in Cloudflare Workers

Ultimately, while Sahil’s suggestion was an excellent alternative, I decided to stick with the cron job architecture using Cloudflare Workers for now, as it provided the best balance of simplicity, flexibility, and cost-efficiency for my use case.

Final Architecture of Bizmo.Social

The finalized architecture for Bizmo.Social is as follows:

  1. Database-Centric :

    • The database acts as the single source of truth for all scheduled posts.
    • Users can freely edit or reschedule posts without worrying about queue management.

  2. Cron Job-Based Scheduling:

    • Cloudflare Workers run a cron job every minute to query the database for scheduled posts.

  3. Queue-Based Processing:

    • The cron job pushes posts into a queue for processing.
    • Cloudflare Workers consume the queue and publish posts to social media platforms.

  1. Dynamic Validation and Flexibility:

    • Since the cron job fetches posts directly from the database, any changes to the post data are automatically reflected in real-time.

Key Takeaways and Lessons Learned

**Collaborate and Learn: Discussions with peers, such as Sahil, helped me explore alternative approaches to improve my architecture. Honestly, if I had asked him earlier, I could have saved myself the headache of overthinking and migrating architecture. But hey, what’s a project without a few sleepless nights and a lot of “Why didn’t I think of this sooner?” moments? .

What’s Next for Bizmo.Social?

With the architecture finalized, the next steps include:

  • Adding support for more social media platforms and video scheduling.
  • Implementing analytics dashboards for tracking post performance.
  • Continuing to refine the user experience for scheduling and publishing.

Building Bizmo.Social has been a rewarding journey, and I’m excited to see how the platform evolves as I continue developing it.

Built by sreeragh.