What It Is

SlotTurf is a turf booking platform for local sports venues. Users browse available slots, book in under 60 seconds, and pay online. No calls, no WhatsApp back-and-forth, no double bookings.

Venue owners get a dashboard to manage slots, pricing, and bookings without touching a spreadsheet.

Architecture

Split into two services:

Frontend Next.js + TypeScript, deployed on Vercel. TanStack Query handles data fetching and cache invalidation. Zustand for client state. Built as a PWA installable on mobile, browsable offline.

Backend Go REST API with the Gin framework, containerized and deployed on GCP Cloud Run. Stateless, auto-scales to zero when idle, scales up on traffic without manual intervention. Cold start is fast enough for the use case.

Database PostgreSQL via Supabase. Supabase handles connection pooling, row-level security policies for multi-tenant venue data, and real-time slot availability. Schema designed to prevent double bookings at the database level slot locking happens in a transaction, not in application code.

Features

• Venue Discovery: Browse and filter by location, sport type, and slot availability
• Real-Time Slots: Availability checked against database state no stale UI, no double bookings
• PWA: Installable on Android and iOS, works offline for browsing cached venue data
• Owner Dashboard: Manage slots, pricing blocks, and booking history

Payment Flow

Razorpay handles payments with server-side order creation and signature verification:

1. User selects slot slot status set to pending in a DB transaction
2. POST /api/payment/create-order hits Go backend, creates Razorpay order server-side
3. Razorpay checkout modal opens client-side
4. On success: payment signature verified server-side in Go before any booking is confirmed
5. Slot status updated to confirmed, booking record created atomically
6. If payment fails or times out: slot released back to available

Signature verification happens in Go before the booking is written. No client-side trust.

Why Go for the Backend

The frontend was already in Next.js. Go was chosen for the backend specifically stateless HTTP handlers, easy containerization for Cloud Run, and straightforward concurrency for handling simultaneous booking requests on the same slot without race conditions.

This is also where I moved beyond tutorial Go into production patterns: context propagation, graceful shutdown, structured logging, and database transaction management for slot locking.