The Challenge

I wanted to build a scheduling platform like Cal.com with three constraints:

• Budget: Under $50/month
• Performance: Sub-100ms response times globally
• Scalability: Handle 10k+ users later

Here's the architecture I chose and why it works (plus where it breaks).

System Architecture

The Stack: 4 Components, Maximum Impact

1. Cloudflare Workers + Hono.js (The Bouncer)

Why: 100k free requests/day, sub-50ms global latency, built-in DDoS protection

What it does:

• Serves static files (HTML, CSS, JS)
• Basic auth validation (JWT verification)
• Rate limiting (100 req/min per IP)
• Blocks 80% of requests from hitting expensive servers

// Lightweight auth check
app.use('/api/*', async (c, next) => {
  const token = c.req.header('Authorization')
  if (token && !await verifyJWT(token)) {
    return c.json({error: 'Invalid token'}, 401)
  }
  await next()
})

2. Express.js on AWS EC2 (The Brain)

Why: No cold starts, predictable costs, WebSocket support

Handles: Booking logic, user management, calendar integrations, email notifications

Why not Lambda? Cold starts (2-3 seconds) kill booking experience.

3. PostgreSQL on RDS (The Memory)

Why: ACID transactions prevent double-bookings, complex availability queries

-- Find available slots (try this in MongoDB!)
SELECT time_slot FROM generate_series(
  '09:00'::time, '17:00'::time, '30 minutes'
) WHERE NOT EXISTS (
  SELECT 1 FROM bookings 
  WHERE time_slot BETWEEN start_time AND end_time
);

4. Redis + Cloudflare R2 (The Cache & Storage)

• Redis: Sessions, rate limits (runs on same EC2 = $0 extra)
• R2: Profile pics, attachments (10x cheaper than S3)

How a Booking Actually Works

1. User visits /book/john → Workers serve static page (50ms globally)
2. Selects time slot → Workers check auth, forward to Express (100ms)
3. Express creates booking → PostgreSQL transaction + Redis cache (200ms)
4. Background job → Send emails, sync calendar (async)

Total user wait time: 300ms

Cost Breakdown: Every Dollar Justified

Compare to alternatives:

• Vercel + PlanetScale: $80-150/month
• Firebase: $100-300/month
• AWS Lambda setup: $60-120/month

Scaling Path: No Rewrites Needed

• Phase 1 (MVP): Current setup
• Phase 2 (1k-10k users): Add read replica ($16), upgrade EC2 ($20)
• Phase 3 (10k+ users): Load balancer, multiple instances, microservices

Each phase builds on the previous—no architecture rewrites.

Where This Architecture BREAKS 💥

Let me be honest about the weaknesses:

When NOT to Use This Architecture

❌ Don't use this if:

• You need 99.99% uptime SLA
• You have global users who need <100ms API responses
• You're building complex real-time collaboration features
• Your team isn't comfortable with distributed systems debugging
• You need to handle traffic spikes >10x normal load

✅ Perfect for:

• MVP with <10k users
• Budget-conscious startups
• Simple booking workflows
• Single-region users initially
• Learning system design

Key Lessons Learned

• Start simple, scale smart - This architecture buys you time to validate product-market fit
• Edge-first saves money - 80% cost savings by handling requests at the edge
• Monitoring is crucial - Single points of failure require excellent monitoring
• Plan your breaking points - Know exactly when you'll need to upgrade each component

The Bottom Line

This architecture works brilliantly for getting to market fast and cheap. It fails when you need enterprise reliability or global performance.

My recommendation: Use this to build your MVP, get your first 1000 users, and generate revenue. Then invest that revenue in a more robust architecture.

The best architecture isn't the most scalable—it's the one that gets you to profitability.