SlotLock

The only appointment booking system where double-booking is physically impossible — backed by AWS Aurora DSQL's strong consistency guarantees.

Comment

Inspiration

Small businesses lose real money to scheduling mix-ups. Salons, tutors, and doctors face the same problem constantly — two customers somehow end up booked for the same time slot. We looked at how tools like Calendly handle this and found they rely on app-level checks that fail under simultaneous requests. A race condition at the wrong moment means two people show up at the same time.

We wanted to fix this at the database level, not the application level. Aurora DSQL made that possible.

What it does

SlotLock is a B2B SaaS booking platform for small businesses. A business owner signs up, creates available time slots, and gets a shareable public booking link to send to customers. Customers click the link, pick a slot, and confirm their booking.

The core guarantee: no two customers can ever book the same slot, even if they click "Confirm" at the exact same millisecond from different devices. The moment a slot is booked, it's gone for everyone else — instantly and permanently.

How we built it

  • Frontend: Next.js App Router, Tailwind CSS, shadcn/ui — scaffolded and iterated with v0
  • Backend: Next.js API routes handling business creation, slot management, and booking logic
  • Database: AWS Aurora DSQL with a PostgreSQL-compatible schema
  • Deployment: Vercel (Hobby plan)

The anti-double-booking logic lives in a single SQL constraint:

UNIQUE (business_id, start_time)

Combined with an atomic UPDATE WHERE status = 'open', this means only one booking can ever succeed for a given slot. DSQL's strong consistency guarantees this holds even under concurrent requests across regions — something traditional databases cannot promise without distributed locking.

Challenges we ran into

The biggest challenge was understanding where exactly to enforce the no-double-booking guarantee. App-level checks (checking if a slot is open before writing) still have a race condition window. Moving the constraint to the database layer — and choosing a database that actually enforces strong consistency across distributed writes — was the key architectural decision.

We also had to architect the database client to auto-switch between a file-based mock (for local development) and Aurora DSQL (for production on Vercel) based on environment variables, without changing any application code.

Accomplishments that we're proud of

  • A real, working SaaS product that solves a genuine pain point
  • Zero double-bookings guaranteed at the database level, not just application logic
  • A live Resilience Demo page that visually shows the race condition being prevented in real time
  • Clean, production-quality UI with session persistence, shareable booking links, and a business dashboard
  • Full stack deployed at zero personal cost using hackathon credits + Vercel Hobby plan

What we learned

Aurora DSQL is not just a database choice — it's a product feature. The strong consistency guarantee is something we could put in our marketing copy and actually mean it. That's rare. Most databases make you implement distributed locking yourself to get the same guarantee, which adds complexity and still has edge cases. DSQL eliminates the problem at the infrastructure level.

What's next for SlotLock

  • Email/SMS notifications when a slot is booked
  • No-show deposit protection via Stripe (charge customers upfront, refund on attendance)
  • Multi-staff support — one business, multiple calendars
  • Pricing: free tier for 1 calendar, ₹499-999/month per business for unlimited bookings
  • The double-booking guarantee becomes the core differentiator in sales conversations with salons, clinics, and tutoring centers

Built With

Share this project:

Updates