Event Ticketing API — High-Concurrency Ticket Booking Platform

Executive Summary: This event ticketing backend system solves high-concurrency flash-sale race conditions. By marrying lightweight Go goroutines with pessimistic PostgreSQL row-level locking (FOR UPDATE SKIP LOCKED), the architecture mathematically guarantees zero double-booking and strict seat allocation integrity without sacrificing latency.

The Business Problem: The Over-Booking Nightmare

Flash sales for event ticketing represent one of the most brutal engineering challenges in e-commerce. A system sitting at near-zero traffic can instantly spike to 50,000 requests per second the moment a countdown timer hits zero. The primary challenge isn't just serving HTTP requests asynchronously; it's the heavily constrained state.

If a stadium has 1,000 seats left, and 50 users concurrently click 'Buy' for the exact same front-row seat, your database and application must mathematically ensure 1 person succeeds and 49 people are rejected instantly. In naive database architectures without strict locking, race conditions occur—resulting in double-booking, which is financially and reputationally devastating for event organizers.

In event ticketing (flash sales), systems experience sudden burst traffic going from zero to tens of thousands of requests per second. The core challenge is not just serving pages fast, but preventing race conditions during seat allocation. If 50 concurrent users attempt to buy the last 1 available seat, the database and backend layer must mathematically guarantee that exactly 1 transaction succeeds, while the other 49 are instantly rejected.

The Architectural Solution

sequenceDiagram
    participant UserA as User A (Go Thread 1)
    participant UserB as User B (Go Thread 2)
    participant PG as PostgreSQL

    UserA->>PG: BEGIN TRANSACTION
    UserB->>PG: BEGIN TRANSACTION
    
    UserA->>PG: SELECT * FROM seats WHERE id=5 FOR UPDATE SKIP LOCKED
    Note right of PG: Row ID=5 is Locked by Thread 1
    
    UserB->>PG: SELECT * FROM seats WHERE id=5 FOR UPDATE SKIP LOCKED
    Note right of PG: Thread 2 skips immediately. Returns 0 rows.
    
    PG-->>UserB: Seat Unavailable (Fast Fail)
    UserB->>UserB: Return HTTP 409 Conflict
    
    PG-->>UserA: Returns Seat Data
    UserA->>PG: UPDATE seats SET status='reserved' WHERE id=5
    UserA->>PG: COMMIT
    Note right of PG: Row ID=5 Unlocked
    UserA->>UserA: Return HTTP 201 Success

1. Race Condition Elimination (Go Snippet)

To guarantee seat transaction integrity, I implemented pessimistic concurrency control using PostgreSQL row-level locking. Specifically, utilizing the `FOR UPDATE SKIP LOCKED` clause. This ensures that the moment a Go thread attempts to read a seat, the database locks that row. If another Go thread concurrently tries to book the same seat, it does not wait in a queue (which would bottleneck the Go server), but immediately skips it and returns a fast-fail failure response to the client.

func (repo *TicketRepository) ReserveSeat(ctx context.Context, tx *sql.Tx, seatID int, userID int) error {
    // 1. Attempt to lock the seat exclusively without waiting
    var status string
    err := tx.QueryRowContext(ctx, `
        SELECT status 
        FROM seats 
        WHERE id = $1 AND status = 'available' 
        FOR UPDATE SKIP LOCKED`, seatID).Scan(&status)

    if err != nil {
        if err == sql.ErrNoRows {
            // Seat is either already booked, or currently locked by another transaction
            return ErrSeatUnavailable
        }
        return err
    }

    // 2. We have the lock! Safely mutate the state.
    _, err = tx.ExecContext(ctx, `
        UPDATE seats 
        SET status = 'reserved', user_id = $2 
        WHERE id = $1`, seatID, userID)
        
    return err
}

The 'Oh Shit' Moment: Connection Pool Exhaustion

Go's insanely fast goroutines created a new problem down the infrastructure stack. When I load-tested the system with 10,000 concurrent users (CCU), the Go API didn't sweat at all (CPU at 15%). However, the PostgreSQL database instantly crashed with connection refused errors.

The Go application was attempting to open thousands of concurrent TCP connections to PostgreSQL. PostgreSQL by default can only handle ~100 concurrent connections before suffocating. The fix required aggressively tuning Go's built-in `database/sql` variables (`SetMaxOpenConns` to a hard ceiling that wouldn't drown the DB) combined with deploying PgBouncer in front of PostgreSQL to multiplex transaction connections.

Measurable Results (Benchmarks)