DEV Community: Konstantin

How I Solved Double-Booking Race Conditions in a Multi-Tenant SaaS — No Redis, No Distributed Locks

Konstantin — Wed, 29 Jul 2026 11:50:41 +0000

Two clients open the same salon's booking page. Both pick 2:00 PM on Friday. Both hit "Confirm" within 200ms of each other.

Without a fix at the database level, both requests pass validation, both inserts succeed, and now the stylist has two people showing up for the same chair.

This is a classic time-of-check-to-time-of-use (TOCTOU) race condition, and it's one of the first hard problems I hit building Pronto, an open-source booking, CRM and POS platform for service businesses. Here's the exact bug, why the obvious fixes don't fully close it, and the Postgres trigger that does.

Why the obvious fix doesn't work

The natural first instinct is application-level:

// ❌ Looks safe. Isn't.
const existing = await supabase
  .from('appointments')
  .select('id')
  .eq('employee_id', employeeId)
  .lt('starts_at', endsAt)
  .gt('ends_at', startsAt)

if (existing.data?.length) {
  return Response.json({ error: 'Slot taken' }, { status: 409 })
}

await supabase.from('appointments').insert({ employeeId, startsAt, endsAt })

This works fine in manual testing. It breaks under real concurrency, because the SELECT and the INSERT are two separate round trips. Two requests can both run the SELECT, both see zero conflicts, and both proceed to INSERT — the classic race window between "check" and "use."

A unique constraint on (employee_id, starts_at) doesn't solve it either, for two unrelated reasons:

It only catches exact-same-start-time collisions. A 2:00–2:30 booking and a 2:15–2:45 booking overlap but don't share a starts_at — the constraint lets both through.
employee_id can be NULL (a booking not yet assigned to a specific staff member). In SQL, NULL = NULL evaluates to NULL, not true — so a plain uniqueness constraint silently stops enforcing anything the moment staff assignment is optional. ## The fix: push the check into the same transaction as the write

The only way to close the race is to make the conflict check and the insert atomic — meaning they happen inside the same database transaction, with the same row-level locking Postgres already uses for writes. A trigger does exactly that.

CREATE OR REPLACE FUNCTION prevent_double_booking()
RETURNS TRIGGER AS $$
BEGIN
  IF EXISTS (
    SELECT 1 FROM appointments
    WHERE business_id = NEW.business_id
      AND employee_id IS NOT DISTINCT FROM NEW.employee_id
      AND id IS DISTINCT FROM NEW.id
      AND status NOT IN ('cancelled', 'no_show')
      AND NEW.starts_at < ends_at
      AND NEW.ends_at > starts_at
  ) THEN
    RAISE EXCEPTION 'SLOT_CONFLICT: overlapping appointment for this employee'
      USING ERRCODE = 'P0001';
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_prevent_double_booking
  BEFORE INSERT OR UPDATE ON appointments
  FOR EACH ROW EXECUTE FUNCTION prevent_double_booking();

Two details matter more than they look like they should:

IS NOT DISTINCT FROM instead of =. This is the NULL-safe equality operator in Postgres. NULL = NULL is NULL (falsy), but NULL IS NOT DISTINCT FROM NULL is true. Without this, two unassigned bookings for the same business at the same time sail straight past the check — the exact case a plain unique constraint also misses.

The overlap condition, not an exact-match condition. NEW.starts_at < ends_at AND NEW.ends_at > starts_at catches any interval overlap, not just identical start times. This is the standard interval-overlap test, and it's the part a naive starts_at = starts_at comparison always gets wrong.

Because this runs inside the same BEFORE INSERT trigger as the write itself, Postgres's row-level locking makes the check-and-write atomic. There's no window between "checked" and "inserted" for a second request to sneak through — the second transaction simply sees the first one's row as soon as it commits, or blocks briefly if they land at the exact same instant.

Surfacing the conflict to the client

The trigger raises a Postgres exception. The API layer catches it and maps it to a proper HTTP status:

try {
  await supabase.from('appointments').insert({ employeeId, startsAt, endsAt })
} catch (err) {
  if (err.message?.includes('SLOT_CONFLICT')) {
    return Response.json(
      { error: 'This slot was just booked. Please pick another time.' },
      { status: 409 }
    )
  }
  throw err
}

409 Conflict is the correct status here — it's not a validation error (400) and it's not a server failure (500), it's "your request was valid when you made it, but the resource state changed underneath you." The frontend listens specifically for 409, refetches the slot grid, and shows the client a clear message instead of a generic error toast.

What this doesn't solve

Worth being honest about the edges:

This protects against overlapping bookings for the same employee within the same business (business_id is in the check, so multi-tenant isolation holds — one tenant's schedule can never block another's). It does not, by itself, stop a business from double-booking a shared resource that isn't modeled as an "employee" (a single treatment room used by two staff, for example) — that needs the same pattern applied to whatever column represents the actual constrained resource.
Cancelled and no-show appointments are explicitly excluded from the conflict check (status NOT IN ('cancelled', 'no_show')). Skipping this filter is a subtle bug of its own: without it, cancelling a booking and rebooking the same slot immediately after would incorrectly conflict with itself.
IS DISTINCT FROM NEW.id matters for the UPDATE case — without it, updating an existing appointment's notes would trip the trigger against itself, since it would find its own row as a "conflict." ## Why a database trigger and not Redis or app-level locking

For a single-instance deployment (which covers most self-hosted installs of Pronto, and a good chunk of small SaaS tenancy patterns), pulling in Redis for a distributed lock is real infrastructure for a problem Postgres already solves natively. Row-level locking inside a trigger is:

Zero extra infrastructure — no Redis instance to provision, monitor, or pay for
Correct by construction — the guarantee comes from the database's own transaction isolation, not from an assumption that every code path remembers to acquire a lock
Impossible to bypass by accident — even a raw SQL insert from a script, a migration, or an admin tool goes through the same trigger; an application-level check only protects code paths that remember to call it If you're running multiple app instances behind a load balancer, this still holds — the guarantee lives in Postgres, not in any one instance's memory, so it doesn't matter how many API servers are hitting the database concurrently.

The pattern generalizes

Anywhere you have "no two rows should overlap on some resource + time interval," this same shape applies: room bookings, equipment reservations, shift scheduling, rental systems. The three pieces are always the same — a BEFORE INSERT OR UPDATE trigger, a NULL-safe comparison on whatever "resource" column can be optional, and an interval-overlap condition instead of an exact-match condition.

Pronto is open-source under MIT. If you're building something with the same overlap-scheduling problem, the full implementation is in the migrations folder.

GitHub: github.com/SGrappelli/pronto
Live demo: demo.trypronto.app

3 security bugs I shipped in my open-source SaaS — and how I fixed them

Konstantin — Fri, 29 May 2026 11:02:29 +0000

Shipping fast as a solo founder means you will introduce security bugs. That's not a question of skill — it's a question of bandwidth. The question is whether you catch them before someone else does.

I'm building Pronto — an open-source self-hosted POS, CRM, and booking system for service businesses. During a security review of v1.0, I found three issues that made me genuinely uncomfortable. None were exploited. All are now fixed.

Here's what they were, why they happened, and how I fixed each one.

Bug 1: Bot tokens leaking to client-side HTML

What happened

Pronto supports Telegram, WhatsApp, and Viber notifications. Each tenant configures their own bot credentials in Settings. These credentials are stored in the database and used server-side to dispatch notifications.

In an early version, I had a notification preview endpoint that fetched tenant settings — including bot tokens — and returned them in a JSON response that was consumed directly by a client-side component.

The token never appeared visibly in the UI. But it was sitting in a fetch response, readable from the browser's DevTools network tab.

// ❌ WRONG — this response reached the client
const settings = await fetch('/api/settings/notifications')
// response included: { telegram_token: "7412...", viber_token: "1234..." }

Any user logged into that tenant's account could extract their own bot token from the browser. For multi-tenant SaaS, this is a real problem — especially if a tenant's account gets compromised.

Why it happened

I built the notifications settings UI quickly and pulled the same endpoint used for server-side rendering. The path of least resistance was "fetch everything, display what you need." The token fields weren't rendered in the UI, so it felt safe. It wasn't.

The fix

All notification dispatch moved to server-only API routes protected by an internal secret header. Client-facing endpoints now return only non-sensitive configuration (enabled/disabled state, phone number prefix for display) — never credentials.

// ✅ Server-side only — internal routes
// middleware checks: req.headers['x-internal-secret'] === process.env.INTERNAL_API_SECRET

// ✅ Client receives only display data
const settings = await fetch('/api/settings/notifications/display')
// response: { telegram_enabled: true, whatsapp_number_preview: "+1 234 ***" }

Rule learned: If it looks like a credential, it never touches the client. Not even in a field that isn't rendered.

Bug 2: Unauthenticated API endpoint

What happened

The public booking page — where clients book appointments without creating an account — needs to fetch available time slots for a given business. This endpoint is intentionally public. No auth required.

However, the same route handler also accepted a staff_id parameter and, when provided, returned full staff profile data including internal notes and contact details that were never meant to be public.

GET /api/public/slots?business=salon-maya&staff_id=123
// returned available slots ✅
// also returned: { name, phone, internal_notes, salary_type } ❌

Why it happened

The staff lookup was added to pre-fill the booking form when a client clicks a specific staff member's profile. I reused an existing staff fetch function without thinking about what data it exposed. The function was designed for internal admin use.

The fix

Public endpoints now use dedicated lean serializers that explicitly whitelist fields:

// ✅ Public staff serializer — only what the booking page needs
function serializeStaffPublic(staff) {
  return {
    id: staff.id,
    name: staff.display_name,
    avatar_url: staff.avatar_url,
    services: staff.services,
  }
  // internal_notes, phone, salary_type — never included
}

Rule learned: Never reuse internal data fetchers for public endpoints. Write a separate serializer that explicitly lists what's allowed out.

Bug 3: In-memory rate limiting that restarts on deploy

What happened

The public booking form is rate-limited to prevent spam. I implemented this with a simple in-memory store:

// ❌ In-memory rate limiter
const attempts = new Map() // { ip: { count, resetAt } }

export function checkRateLimit(ip) {
  const record = attempts.get(ip)
  if (record && record.count >= 10 && Date.now() < record.resetAt) {
    return false // rate limited
  }
  // update record...
  return true
}

This works fine in development. In production, every container restart wipes the Map. Every deploy resets all rate limit counters. A bad actor who knows your deploy schedule (or just retries after a restart) bypasses the limit entirely.

For a SaaS with multiple instances, it's even worse — each instance has its own Map, so the effective limit is N instances × 10 requests.

Why it happened

In-memory is the fastest path to "rate limiting is implemented." It works in local testing. The failure mode only appears in production at scale or with deliberate probing.

The fix

The proper solution is Redis (Upstash works well for serverless). But I documented it as a known limitation with a clear upgrade path rather than blocking the release:

// ✅ Production path — Redis via Upstash
import { Ratelimit } from '@upstash/ratelimit'
import { Redis } from '@upstash/redis'

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, '1 h'),
})

const { success } = await ratelimit.limit(ip)

For self-hosted single-instance deployments, the in-memory version is documented as acceptable with the caveat clearly stated in README. For SaaS — Redis is required.

Rule learned: In-memory state that needs to survive restarts is a production bug, not a dev shortcut. Either implement it properly or document the limitation explicitly so users aren't surprised.

The meta-lesson

All three bugs share a root cause: I made the "fast path" decision without thinking about the security surface.

Fastest notification settings: return everything to the client
Fastest staff lookup: reuse the existing function
Fastest rate limiting: in-memory Map

Speed of implementation and security surface are often in tension. When you're building solo, you need a personal forcing function to catch this tension before it ships.

Mine is now: anything that touches credentials, user data, or auth gets a 5-minute threat model before it goes to production. Not a formal audit. Just five minutes of "who can call this, what can they get, what happens if this is wrong."

It has caught two more issues since I formalized it.

Pronto is open-source under MIT. If you find something I missed — issues are open.

GitHub: github.com/SGrappelli/pronto
SaaS: trypronto.app

How I built subdomain-based multi-tenancy with Next.js 14, Supabase RLS, and Cloudflare — for free

Konstantin — Wed, 06 May 2026 11:13:58 +0000

Multi-tenancy is one of those things that sounds simple until you're three hours deep into middleware, wildcard DNS, and Row Level Security policies wondering where it all went wrong.

I built it for Pronto — an open-source POS, CRM, and booking system for service businesses. Every business that signs up gets their own subdomain: salon-maya.trypronto.app. Fully isolated. One codebase.

Here's exactly how I did it, what broke, and what I'd do differently.

The architecture in one diagram

Client request: salon-maya.trypronto.app
        ↓
Cloudflare (wildcard *.trypronto.app → DigitalOcean)
        ↓
Next.js Middleware (extract slug from hostname)
        ↓
Supabase RLS (row-level isolation per business_id)
        ↓
Tenant data

Three layers. Each one solves a different problem.

Layer 1: Cloudflare wildcard DNS

This is the easiest part. In your Cloudflare dashboard, add one DNS record:

Type: A
Name: *
Content: your-server-ip
Proxy: ✅ (orange cloud)

One record handles every subdomain. salon-maya, barbershop-joe, cafe-lima — all routed to the same server automatically.

Then enable Universal SSL and make sure it covers wildcard *.yourdomain.com. Cloudflare's free plan does this.

That's it for DNS. Cost: $0.

Layer 2: Next.js Middleware — extracting the tenant

Every request needs to know which tenant it belongs to. Middleware runs before any page renders, which makes it the right place for this.

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || ''
  const baseDomain = process.env.NEXT_PUBLIC_BASE_DOMAIN || 'trypronto.app'

  // salon-maya.trypronto.app → slug = "salon-maya"
  const slug = hostname.replace(`.${baseDomain}`, '')

  // Skip if it's the root domain
  if (slug === baseDomain || slug === 'www') {
    return NextResponse.next()
  }

  // Pass slug to the request via header
  const requestHeaders = new Headers(request.headers)
  requestHeaders.set('x-tenant-slug', slug)

  return NextResponse.next({
    request: { headers: requestHeaders }
  })
}

export const config = {
  matcher: ['/((?!api|_next/static|_next/image|favicon.ico).*)'],
}

Then in any Server Component or API route, read it back:

import { headers } from 'next/headers'

export default async function Page() {
  const headersList = headers()
  const slug = headersList.get('x-tenant-slug')

  const business = await getBusinessBySlug(slug)
  // ...
}

Layer 3: Supabase RLS — the real isolation

Passing a slug through headers is fine for routing, but if your database queries don't enforce tenant isolation at the DB level, you have a security problem.

Supabase Row Level Security fixes this.

Every tenant table has a business_id column:

create table businesses (
  id uuid primary key default gen_random_uuid(),
  slug text unique not null,
  name text not null,
  owner_id uuid references auth.users(id)
);

create table appointments (
  id uuid primary key default gen_random_uuid(),
  business_id uuid references businesses(id) not null,
  client_name text,
  starts_at timestamptz
);

Enable RLS and add a policy:

alter table appointments enable row level security;

create policy "appointments_business_isolation"
  on appointments
  using (
    business_id = (
      select id from businesses 
      where owner_id = auth.uid()
    )
  );

Now it's physically impossible for one tenant to read another tenant's data, even if there's a bug in your application layer.

Migration files — keep it simple:

I use numbered SQL files (001_initial.sql, 002_add_rls.sql) and a Node script that applies them in order on startup. No ORM magic — just SQL tracked in git.

// scripts/migrate.js
const migrations = await fs.readdir('./supabase/migrations')
const sorted = migrations.sort() // 001_, 002_, etc.

for (const file of sorted) {
  // Check if already applied, skip if so
  // Execute if new
}

The onboarding flow

When a new business registers, they pick their slug:

What's your business URL?
[ salon-maya ] .trypronto.app

On submit:

// Validate slug is URL-safe and available
const slug = input.toLowerCase().replace(/[^a-z0-9-]/g, '')

const existing = await supabase
  .from('businesses')
  .select('id')
  .eq('slug', slug)
  .single()

if (existing.data) {
  return { error: 'This URL is already taken' }
}

// Create the business record
const { data: business } = await supabase
  .from('businesses')
  .insert({ slug, name: businessName, owner_id: userId })
  .select()
  .single()

// Redirect to their new subdomain
redirect(`https://${slug}.trypronto.app/onboarding`)

No DNS configuration needed on the customer's side. The wildcard handles it instantly.

What broke (and how I fixed it)

Problem 1: Cookies don't cross subdomains by default.

salon-maya.trypronto.app and trypronto.app are different origins. A session cookie set on the root domain won't be readable on the subdomain.

Fix — set the cookie domain with a leading dot:

response.cookies.set('sb-token', token, {
  domain: '.trypronto.app', // note the leading dot
  httpOnly: true,
  secure: true,
  sameSite: 'lax'
})

Problem 2: Middleware fired on static assets.

Without the matcher config, middleware runs on every _next/static/... request and adds latency to every image and JS chunk. The matcher I showed above fixes this.

Problem 3: Double-booking at the application layer.

Two concurrent requests could both pass the "is this slot free?" check before either wrote to the database. Fixed with a PostgreSQL trigger:

create or replace function prevent_double_booking()
returns trigger as $$
begin
  if exists (
    select 1 from appointments
    where business_id = NEW.business_id
      and employee_id IS NOT DISTINCT FROM NEW.employee_id
      and status != 'cancelled'
      and tstzrange(starts_at, ends_at) && tstzrange(NEW.starts_at, NEW.ends_at)
      and id != NEW.id
  ) then
    raise exception 'SLOT_CONFLICT' using errcode = 'P0001';
  end if;
  return NEW;
end;
$$ language plpgsql;

The API returns HTTP 409 on conflict. No race condition possible.

Custom domains (bonus)

For customers who want booking.their-salon.com instead of a subdomain, Cloudflare for SaaS handles this. The first 100 custom domains are free.

The customer adds a CNAME pointing to your domain, you verify ownership, Cloudflare provisions the SSL certificate automatically. From your app's perspective, it's the same middleware pattern — just match on the full hostname instead of extracting a slug.

The full cost breakdown

Layer	Tool	Cost
Wildcard DNS + SSL	Cloudflare	$0
Subdomain routing	Next.js middleware	$0
Tenant isolation	Supabase RLS	$0
Custom domains	Cloudflare for SaaS	$0 (first 100)
Hosting	DigitalOcean	~$20/mo

The entire multi-tenancy infrastructure costs $20/month — just the server.

The code is open source

Pronto is MIT-licensed. If you're building something similar — a SaaS for service businesses, a booking system, anything with subdomain tenancy — the full implementation is there to read.

⭐ github.com/SGrappelli/pronto

Live demo: trypronto.app

Questions about any layer? Drop them in the comments.

How I built an open-source POS with Telegram, WhatsApp & Viber — one Docker command install

Konstantin — Wed, 29 Apr 2026 12:42:36 +0000

A friend of mine runs a beauty salon. Every evening she manually texts appointment reminders to her clients. She tracks inventory in Excel. And she pays 20% commission to a booking platform — for clients she spent years building relationships with herself.
So I built Pronto: an open-source POS, CRM, booking system, inventory tracker, and omnichannel notification engine for service businesses. Self-hosted or cloud. Zero commission. One command to install.
This post is about the technical decisions that were actually hard.

The architecture in one paragraph

Next.js 14 API routes + Supabase (PostgreSQL + Auth) + Cloudflare R2 for file storage. Notifications via Resend/SMTP, Telegram Bot API, Meta WhatsApp Cloud API, and Viber Bot API. Docker Compose for self-hosting. PWA via next-pwa for offline POS. Multitenancy via Supabase Row Level Security.
Credential model: each self-hoster (or SaaS tenant) brings their own API keys — Telegram bot token, WhatsApp Phone Number ID + Access Token, Viber token. The platform owner pays nothing to the messenger providers.

Problem 1: The double-booking race condition

App-level booking conflict checks have a classic race condition. Two clients simultaneously pick the same slot → both pass the check → both get confirmed.
The fix: a PostgreSQL trigger that runs atomically at commit time.

CREATE OR REPLACE FUNCTION check_booking_conflict()
RETURNS TRIGGER AS $$
BEGIN
  IF EXISTS (
    SELECT 1 FROM bookings
    WHERE business_id = NEW.business_id
      AND employee_id IS NOT DISTINCT FROM NEW.employee_id
      AND status NOT IN ('cancelled', 'no_show')
      AND (NEW.start_time, NEW.end_time) OVERLAPS (start_time, end_time)
      AND id != NEW.id
  ) THEN
    RAISE EXCEPTION 'Booking conflict: slot already taken';
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

IS NOT DISTINCT FROM handles the NULL case — when employee_id is NULL (group bookings), it still works correctly. The API returns HTTP 409 on conflict, and the UI refreshes the slot grid automatically.

Problem 2: Docker broke auth callbacks

The app worked perfectly locally. Inside a Docker container, Supabase auth redirected back to http://0.0.0.0:3000/auth/callback — because request.url resolves to the container's internal address, not the real hostname.
The fix: read NEXT_PUBLIC_SITE_URL explicitly instead of deriving origin from the request.

const siteUrl = process.env.NEXT_PUBLIC_SITE_URL || 'http://localhost:3000'
const { data, error } = await supabase.auth.exchangeCodeForSession(code)
return NextResponse.redirect(`${siteUrl}/dashboard`)

This made the install truly one-command — no post-install auth debugging required.

Problem 3: WhatsApp's 24-hour window

Nobody documents this clearly upfront: Meta Cloud API only allows free-form text within a 24-hour window after the client initiates contact. Business-initiated messages — appointment reminders, birthday greetings, re-activation nudges — require pre-approved Message Templates (HSM) submitted through Meta Business Manager.
This matters if you're building anything that sends proactive notifications via WhatsApp. You either get your templates approved first, or your reminder system silently fails for business-initiated messages. I documented this honestly in the README as a known limitation.

Automatic migrations on startup

Self-hosters shouldn't have to run database migrations manually. I wrote a scripts/migrate.js that runs all Supabase migrations in order before the app starts, using the pg library directly.

# docker-compose.yml
services:
  migrate:
    build: .
    command: node scripts/migrate.js
    depends_on:
      db:
        condition: service_healthy

  app:
    build: .
    depends_on:
      migrate:
        condition: service_completed_successfully

The service_completed_successfully condition means the app won't start until all 18 migrations have run cleanly. docker compose up -d is now genuinely one command.

The full stack

Frontend: Next.js 14 + Tailwind + shadcn/ui
Backend: Next.js API routes + Supabase
Database: PostgreSQL (Supabase), 18 migrations
Auth: Supabase Auth — Email + Google OAuth
Notifications: Resend, Telegram Bot API, Meta WhatsApp Cloud API, Viber Bot API
Storage: Cloudflare R2
Self-hosting: Docker Compose, multi-stage build, non-root user
PWA: next-pwa 5.6.0, IndexedDB for offline POS
i18n: next-intl 4.9.0 (EN active, more coming)

What's live in v1.0

POS — completes a sale in 3 clicks, works offline via PWA + IndexedDB
CRM — full client history, visit patterns, birthday, tags, notes
Booking calendar — drag & drop, week view, staff columns
Public booking page — name + phone only, no client account required
Inventory — stock tracking, low-stock alerts via all channels
Notifications — all 4 channels fire automatically: booking confirmed → 24h reminder → 1h reminder → thank-you → 30-day re-activation → birthday → low-stock
Multitenancy — each business isolated via Supabase RLS, own subdomain.

Running costs at zero customers

~$20–25/month on an existing DigitalOcean server. One Starter customer ($19/mo) covers it. Two Pro customers ($39/mo) puts it in the green.

What I'm still figuring out

Payment processing as a solo founder based in Georgia (the country) is genuinely difficult. LemonSqueezy and Polar.sh both don't support bank payouts to Georgia. Paddle has been pending verification for two weeks. Currently testing Dodo Payments. If you've solved this from a non-Stripe-supported country, I'd genuinely appreciate knowing what worked.

GitHub: github.com/SGrappelli/pronto — MIT, Docker Compose, CI/CD
Live cloud version: trypronto.app
Happy to answer questions about any of the technical decisions above.