Build Secure Ticketing with Laravel & Octane

Why a Ticket Booking Platform Is Not Just Another Shop

A seat isn’t a SKU. Once a specific seat is sold, it’s gone—there’s no restocking a front-row chair for a sold-out concert. That single constraint distinguishes ticketing from generic e-commerce and forces you to solve for:

Real-time seat allocation
Double-booking prevention under high concurrency
Secure, idempotent payment processing
Instant digital fulfillment (e-tickets with QR codes)
Consistent user experience under burst traffic (on-sale moments)

In this guide, you’ll learn how to build a reliable, scalable online ticket booking platform with Laravel. We’ll combine Laravel Octane (for high concurrency), MySQL transactions (for atomic state changes), Redis locks (for fast contention control), and Stripe (for secure payments), and we’ll round it out with QR e-ticket generation and operational best practices.

Architecture Overview

A modern, reliable ticketing system typically includes:

Web/API layer: Laravel with Octane (Swoole or RoadRunner)
Data store: MySQL (with strong relational integrity) + Redis (for locks and caching)
Payments: Stripe (Payment Intents + webhooks)
Queues and workers: Redis-backed queues with Laravel Horizon
Realtime: Broadcasting seat updates via Pusher/Ably/Laravel WebSockets
Storage: S3-compatible object storage for QR codes and tickets
Observability: Logs, metrics, error tracking, alerts

Key considerations:

Every state change that involves inventory (seats) must be ACID-transactional.
Don’t trust the client for price or availability—always validate server-side.
Payments must be idempotent and confirmed via webhook before issuing tickets.
Long operations (QR generation, email) belong to queues, not HTTP requests.

Data Modeling for Seats, Orders, and Tickets

Start with a schema that makes seat-level locking and accounting easy. A simplified set:

venues (id, name, address)
events (id, venue_id, name, starts_at, ends_at)
seats (id, venue_id, section, row, seat_number, seat_label)
seat_pricings (id, event_id, seat_id, price_cents, currency, fee_cents)
orders (id, user_id, event_id, status [pending, paid, failed, refunded], total_cents, currency, payment_intent_id, created_at)
order_items (id, order_id, seat_id, price_cents, fee_cents)
tickets (id, order_id, seat_id, ticket_code, qr_path, status [issued, void], issued_at)
seat_locks (id, event_id, seat_id, user_id, locked_until, order_id nullable)

Seat locks are temporary reservations that block others from selecting the same seat while a user is checking out. You can also model locks transiently in Redis to avoid table growth, but having a persistent record helps auditing and conflict resolution. A hybrid approach works well: a Redis lock for fast mutual exclusion and a DB row for authoritative state.

Example Migrations (abridged)

// database/migrations/xxxx_xx_xx_create_orders_and_tickets.php
Schema::create('orders', function (Blueprint $table) {
    $table->id();
    $table->foreignId('user_id')->nullable()->constrained();
    $table->foreignId('event_id')->constrained();
    $table->string('status')->default('pending');
    $table->bigInteger('total_cents')->default(0);
    $table->string('currency', 3)->default('USD');
    $table->string('payment_intent_id')->nullable()->index();
    $table->timestamps();
});

Schema::create('order_items', function (Blueprint $table) {
    $table->id();
    $table->foreignId('order_id')->constrained();
    $table->foreignId('seat_id')->constrained();
    $table->bigInteger('price_cents');
    $table->bigInteger('fee_cents')->default(0);
    $table->timestamps();
});

Schema::create('tickets', function (Blueprint $table) {
    $table->id();
    $table->foreignId('order_id')->constrained();
    $table->foreignId('seat_id')->constrained();
    $table->string('ticket_code')->unique();
    $table->string('qr_path')->nullable();
    $table->string('status')->default('issued');
    $table->timestamp('issued_at')->nullable();
    $table->timestamps();
});

Schema::create('seat_locks', function (Blueprint $table) {
    $table->id();
    $table->foreignId('event_id')->constrained();
    $table->foreignId('seat_id')->constrained();
    $table->foreignId('user_id')->nullable()->constrained();
    $table->foreignId('order_id')->nullable()->constrained();
    $table->timestamp('locked_until')->index();
    $table->timestamps();
    $table->unique(['event_id', 'seat_id']);
});

High Concurrency with Laravel Octane

Laravel Octane keeps your app “hot” in memory, removing per-request bootstrap overhead. This translates to much better throughput and lower latency during flash sales.

Best practices with Octane:

Avoid mutable singletons or per-request state in static properties—memory leaks and data bleed can occur across requests.
Prefer Redis for cross-worker state; don’t rely on Octane’s in-memory tables for anything that must be shared across nodes.
Use Octane::concurrently() for IO-bound tasks (e.g., fetching seat map + pricing), but never split ACID-critical flows across concurrent tasks that must be atomic.
Test under load; some code that’s fine with FPM fails under heavy concurrency with hot processes.

Quick setup:

composer require laravel/octane
php artisan octane:install
php artisan octane:start --server=swoole

Run Octane behind a reverse proxy (Nginx) and supervise with systemd or Supervisor. Ensure graceful shutdown and rolling restarts.

Real-Time Seat Allocation: Locking and Transactions

When multiple users try to buy the same seat, you must ensure exactly one wins.

Tactics:

Database locking with SELECT ... FOR UPDATE inside a transaction prevents concurrent modifications to the same rows.
Redis locks or funnels provide fast mutual exclusion at the application layer for hot keys (e.g., seat:123).
Combine both: Redis for immediate contention control, DB transaction for definitive, durable state.

Locking Flow

User selects seats.
Acquire a short Redis lock per seat (e.g., 5–10 seconds) to avoid dogpiles.
Start a DB transaction.
Check seat availability with a row-level lock.
Create/refresh a seat lock with TTL (e.g., 7 minutes).
Commit transaction and release Redis lock.
Create/confirm Stripe PaymentIntent referencing the order total.
On webhook confirmation, issue tickets, finalize order, and delete seat lock.

Implementing Redis Lock + MySQL Transaction

Laravel provides atomic locks via Cache::lock(), backed by Redis:

use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\DB;
use Carbon\Carbon;

public function holdSeats(int $eventId, array $seatIds, ?int $userId) {
    // Acquire per-seat locks to serialize conflicts quickly
    $locks = [];
    try {
        foreach ($seatIds as $seatId) {
            $lock = Cache::lock("seat:{$eventId}:{$seatId}", 10); // expires in 10s
            if (!$lock->get()) {
                throw new \RuntimeException("Seat {$seatId} is busy. Try again.");
            }
            $locks[] = $lock;
        }

        return DB::transaction(function () use ($eventId, $seatIds, $userId) {
            $now = Carbon::now();
            $ttl = $now->copy()->addMinutes(7); // hold duration

            foreach ($seatIds as $seatId) {
                // Verify no active lock in DB
                $existing = DB::table('seat_locks')
                    ->where('event_id', $eventId)
                    ->where('seat_id', $seatId)
                    ->lockForUpdate() // row-level lock
                    ->first();

                if ($existing && Carbon::parse($existing->locked_until)->isFuture()) {
                    throw new \RuntimeException("Seat {$seatId} already locked.");
                }

                // Upsert lock
                DB::table('seat_locks')->updateOrInsert(
                    ['event_id' => $eventId, 'seat_id' => $seatId],
                    ['user_id' => $userId, 'locked_until' => $ttl, 'updated_at' => $now, 'created_at' => $now]
                );
            }

            // Return a token or lock reference for checkout
            return ['expires_at' => $ttl->toIso8601String()];
        }, 3); // retry on deadlock
    } finally {
        foreach ($locks as $lock) {
            optional($lock)->release();
        }
    }
}

Notes:

lockForUpdate prevents other transactions from modifying the same lock rows concurrently.
DB::transaction with retry helps during rare deadlocks.
The Redis locks deconflict hot seats before hitting the DB to reduce contention.

Cleaner Gatekeeping with Funnels/Throttles

Laravel’s Redis::funnel or Cache::lock are both effective. Funnels enforce a limit of concurrent operations per key. For critical seat operations, limit to 1 per seat:

// With Cache::lock shown above, or alternatively:
use Illuminate\Support\Facades\Redis;

Redis::funnel("seat:{$eventId}:{$seatId}")->limit(1)->then(function () {
    // perform locking transaction
}, function () {
    throw new \RuntimeException('Seat is busy – please retry.');
});

Checkout Flow with Stripe Payment Intents

Stripe’s Payment Intents API supports strong customer authentication and handles complex states. The golden rule: do not create tickets on the client’s “success” page—wait for Stripe’s webhook confirmation to finalize the order.

Server-Side Steps

Create or update an Order in “pending” status with recalculated totals.
Create a Stripe PaymentIntent with the exact amount and currency.
Return the client_secret to the client to complete payment.
Listen to webhooks (payment_intent.succeeded, payment_intent.payment_failed).
On success:
- Atomically consume seat locks
- Mark order as paid
- Issue tickets, generate QR codes, notify user
On failure:
- Release locks or let them expire
- Mark order failed

Creating a PaymentIntent

use Stripe\StripeClient;

public function createOrUpdatePaymentIntent(Order $order): array
{
    $stripe = new StripeClient(config('services.stripe.secret'));

    // Always calculate totals server-side based on seat_pricings:
    $amount = $order->orderItems()->sum(DB::raw('price_cents + fee_cents'));

    $params = [
        'amount' => $amount,
        'currency' => $order->currency,
        'metadata' => [
            'order_id' => (string) $order->id,
            'event_id' => (string) $order->event_id,
        ],
        'automatic_payment_methods' => ['enabled' => true],
    ];

    if ($order->payment_intent_id) {
        $intent = $stripe->paymentIntents->update($order->payment_intent_id, $params);
    } else {
        $intent = $stripe->paymentIntents->create($params, [
            'idempotency_key' => 'order-'.$order->id
        ]);
        $order->payment_intent_id = $intent->id;
        $order->save();
    }

    return ['client_secret' => $intent->client_secret];
}

Important:

Use idempotency keys when creating PaymentIntents to avoid duplicates during retries.
Never accept the amount from the client.
Include metadata for traceability.

Verifying Webhooks

Set up the endpoint and verify signatures:

use Illuminate\Http\Request;
use Stripe\Webhook;

public function handleStripeWebhook(Request $request)
{
    $signature = $request->header('Stripe-Signature');
    $payload = $request->getContent();

    $event = Webhook::constructEvent(
        $payload,
        $signature,
        config('services.stripe.webhook_secret')
    );

    switch ($event->type) {
        case 'payment_intent.succeeded':
            $this->finalizeOrder($event->data->object->id);
            break;
        case 'payment_intent.payment_failed':
            $this->failOrder($event->data->object->id);
            break;
    }

    return response()->json(['received' => true]);
}

Finalizing the Order (Atomic Consumption of Locks)

use Illuminate\Support\Str;

public function finalizeOrder(string $paymentIntentId)
{
    DB::transaction(function () use ($paymentIntentId) {
        $order = Order::where('payment_intent_id', $paymentIntentId)
            ->lockForUpdate()
            ->firstOrFail();

        if ($order->status === 'paid') {
            return; // idempotent
        }

        $now = now();

        // Validate that locks still exist and are ours to consume
        $locks = DB::table('seat_locks')
            ->where('event_id', $order->event_id)
            ->whereIn('seat_id', $order->orderItems()->pluck('seat_id'))
            ->where('locked_until', '>', $now)
            ->lockForUpdate()
            ->get();

        if ($locks->count() !== $order->orderItems()->count()) {
            throw new \RuntimeException('Seat lock expired or missing.');
        }

        // Issue tickets
        foreach ($order->orderItems as $item) {
            Ticket::create([
                'order_id' => $order->id,
                'seat_id' => $item->seat_id,
                'ticket_code' => Str::uuid()->toString(),
                'issued_at' => $now,
                'status' => 'issued',
            ]);
        }

        // Mark order paid
        $order->update(['status' => 'paid', 'total_cents' => $order->orderItems()->sum('price_cents') + $order->orderItems()->sum('fee_cents')]);

        // Cleanup locks
        DB::table('seat_locks')
            ->where('event_id', $order->event_id)
            ->whereIn('seat_id', $order->orderItems()->pluck('seat_id'))
            ->delete();

        // Dispatch async jobs
        dispatch(new GenerateTicketQRCodes($order->id));
        dispatch(new SendOrderConfirmationEmail($order->id));
        broadcast(new SeatsSoldEvent($order->event_id, $order->orderItems()->pluck('seat_id')->all()));
    }, 3);
}

This ensures:

Idempotency via checking order status first.
Atomic ticket issuance and lock consumption.
Lock deletion only after successful ticket creation.

Generating QR E-Tickets

Use a QR library to encode a secure payload for validation at the gate. Avoid encoding raw PII. Instead, include a signed token with limited data.

Recommended approach:

Payload includes ticket_id, order_id, event_id, a short expiry (for validation token), and an HMAC signature.
Validate the token server-side on scan.

Install a QR package:

composer require simplesoftwareio/simple-qrcode

Job example:

use SimpleSoftwareIO\QrCode\Facades\QrCode;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Bus\Queueable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Illuminate\Support\Facades\Storage;

class GenerateTicketQRCodes implements ShouldQueue
{
    use InteractsWithQueue, Queueable, SerializesModels;

    public function __construct(public int $orderId) {}

    public function handle()
    {
        $order = Order::with('tickets')->findOrFail($this->orderId);

        foreach ($order->tickets as $ticket) {
            $payload = $this->buildPayload($ticket);
            $png = QrCode::format('png')->size(600)->margin(1)->generate($payload);

            $path = "tickets/{$ticket->id}.png";
            Storage::disk('s3')->put($path, $png, 'public');

            $ticket->update(['qr_path' => $path]);
        }
    }

    protected function buildPayload(Ticket $ticket): string
    {
        $data = [
            'tid' => $ticket->id,
            'oid' => $ticket->order_id,
            'eid' => $ticket->order->event_id,
            'ts'  => time(),
        ];
        $signature = hash_hmac('sha256', json_encode($data), config('app.qr_secret'));
        $data['sig'] = $signature;
        return json_encode($data);
    }
}

At scanning time, verify the HMAC and check the ticket status hasn’t been used or voided.

Real-Time Seat Updates

To minimize user frustration, reflect seat status changes instantly:

On seat lock creation, broadcast a “SeatHeld” event with expiry timestamp.
On successful purchase, broadcast “SeatsSold.”
On lock expiration, broadcast “SeatReleased.”

Laravel Broadcasting sample:

class SeatsSoldEvent implements ShouldBroadcast
{
    public function __construct(public int $eventId, public array $seatIds) {}

    public function broadcastOn()
    {
        return new PresenceChannel("events.{$this->eventId}");
    }

    public function broadcastAs()
    {
        return 'seats.sold';
    }
}

Use a small client-side buffer to avoid flicker (debounce updates), and always confirm availability server-side at checkout.

Actionable Performance Tips

Indexes: Add composite indexes on seat_locks(event_id, seat_id), order_items(order_id), tickets(order_id, seat_id). For queries by event and seat, ensure covering indexes.
Transaction isolation: Use READ COMMITTED to reduce gap locks unless you rely on REPEATABLE READ semantics. Test both with your workload.
Lock timeouts: Tune innodb_lock_wait_timeout and explicitly time-bound Redis locks to avoid deadlocks cascading.
Hot seats: For limited “VIP” rows, prefetch and cache seat statuses in Redis with short TTL (e.g., 1–3s) to reduce read load; keep DB as source of truth on write.
Octane memory hygiene: Avoid caching request or user objects in singletons. Clear per-request caches using Octane hooks if necessary.
Queue scaling: Use Horizon to scale workers dynamically during on-sales; prioritize jobs (payments > ticket issue > emails).
Idempotency everywhere: For webhooks, use a processed_events table with event IDs to prevent duplicates. For internal jobs, implement unique job constraints.

End-to-End Booking Flow (Step-by-Step)

Browse:
- Client requests event and seat map.
- Server returns seat availability with “held_until” timestamps for locked seats.
Select seats:
- Client posts seat IDs.
- Server acquires Redis locks, starts DB transaction, validates availability, writes/refreshes seat_locks with expiry.
- Returns hold token and expiry.
Checkout:
- Client initiates order creation.
- Server recalculates price from seat_pricings, creates Order + OrderItems, ties to seat_locks by seat IDs.
Payment:
- Server creates/updates Stripe PaymentIntent.
- Client confirms with Elements/Payment Request Button.
- User complete 3DS if required.
Confirmation (webhook-driven):
- payment_intent.succeeded triggers finalizeOrder().
- Atomic: verify locks, issue tickets, mark order paid, delete locks, enqueue QR generation and email.
- Broadcast sold seats.
Post-purchase:
- QR images generated and stored.
- Email with ticket links sent.
- User can download wallet passes or PDFs.
Expirations:
- A scheduled job scans seat_locks for expired locks and deletes them; broadcasts releases.

Practical Code: Seat Availability Endpoint

public function availability(int $eventId)
{
    // Combine DB state with lock expirations
    $locks = DB::table('seat_locks')
        ->where('event_id', $eventId)
        ->where('locked_until', '>', now())
        ->pluck('locked_until', 'seat_id');

    $soldSeatIds = DB::table('tickets')
        ->join('orders', 'tickets.order_id', '=', 'orders.id')
        ->where('orders.event_id', $eventId)
        ->where('orders.status', 'paid')
        ->pluck('tickets.seat_id')
        ->toArray();

    return response()->json([
        'held' => $locks,
        'sold' => $soldSeatIds,
    ]);
}

Cache this response for 1–2 seconds during heavy traffic to smooth load, but always re-check on critical operations.

Handling Edge Cases and Failures

User abandons checkout: seat_locks expire automatically; a scheduler clears them and sends SeatReleased broadcasts.
Payment succeeds but webhook delayed: surface a pending state to the user and poll a status endpoint; keep locks valid a bit longer (buffer).
Webhook sent twice: idempotency via order status and processed_events table avoids duplicate tickets.
Partial seat availability at checkout: if one seat lock has expired, fail the checkout gracefully with specific messaging and suggest alternatives.
Refunds and voids:
- On refund, mark ticket status “void” and broadcast release only if you intend to resell.
- Generate a new QR if exchanging tickets; never reuse codes.

Security Best Practices

Validate all inputs; never accept seat IDs or prices blindly.
Recalculate server-side totals at checkout; compare against PaymentIntent amount.
Secure webhooks by verifying Stripe signatures and limiting IP if possible.
Do not expose internal ticket codes directly; use opaque IDs or signed routes for downloads.
Sign QR payloads and rotate qr_secret if compromised; consider per-ticket salts.
Apply rate limiting on seat hold and payment endpoints.
Keep PII out of QR codes and URLs; store sensitive data server-side only.

Testing Strategy

Unit tests: pricing calculators, lock helpers, QR payload signatures.
Feature tests: end-to-end flow from selection to webhook finalization; fake Stripe or use test keys and test clocks.
Concurrency tests: spawn parallel requests trying to lock the same seat; assert only one succeeds.
Load testing: use k6/Artillery to simulate on-sale spikes; watch DB lock waits and Redis saturation.
Chaos drills: kill worker processes, drop webhook deliveries, and ensure idempotency prevents double issuance.

Example concurrency test sketch:

public function test_only_one_lock_wins_under_race()
{
    $eventId = Event::factory()->create()->id;
    $seat = Seat::factory()->create(['venue_id' => 1]);
    $seatPricing = SeatPricing::factory()->create(['event_id' => $eventId, 'seat_id' => $seat->id]);

    $results = collect(parallel(10, function () use ($eventId, $seat) {
        try {
            return app(SeatService::class)->holdSeats($eventId, [$seat->id], null);
        } catch (\Throwable $e) {
            return null;
        }
    }));

    $successes = $results->filter()->count();
    $this->assertEquals(1, $successes);
}

Deployment and Operations

Horizontal scaling: multiple Octane instances behind a load balancer; Redis and MySQL are shared.
Horizon: manage queues, assign priorities, scale workers for QR generation and emails.
Observability:
- Metrics: orders per minute, webhook latencies, lock wait times, failed jobs.
- Alerts: payment failures spike, lock wait timeout spikes, webhook error rate.
- Tools: Laravel Telescope for debugging in staging; Sentry/Bugsnag for production errors.
Backups and DR: regular MySQL backups, object storage replication, Redis snapshotting for locks is optional but not required since locks are ephemeral.
Configuration:
- Tune MySQL innodb_buffer_pool_size and connection pool.
- Set pconnect limits in Octane and use persistent DB connections cautiously; ensure reconnection handling.
- Ensure time synchronization (NTP) for lock expirations and signed payloads.

Common Pitfalls to Avoid

Issuing tickets before webhook confirmation: credit card authorizations can be reversed; only trust webhooks.
Long HTTP requests: generating QR codes or PDFs inside the request leads to timeouts; offload to queues.
Over-reliance on cache: always revalidate availability in a transaction; caches can be stale under burst load.
Forgetting idempotency: duplicate PaymentIntent creation or webhook processing creates inconsistent states.
Non-expiring locks: always set locked_until and schedule cleanup; don’t block seats indefinitely.

Example Seat Selection Controller (Putting It Together)

class SeatSelectionController extends Controller
{
    public function hold(Request $request, int $eventId)
    {
        $validated = $request->validate([
            'seats' => 'required|array|min:1|max:10',
            'seats.*' => 'integer',
        ]);

        // Re-validate seat IDs belong to the event and exist
        $validSeatIds = SeatPricing::where('event_id', $eventId)
            ->whereIn('seat_id', $validated['seats'])
            ->pluck('seat_id')
            ->toArray();

        if (count($validSeatIds) !== count($validated['seats'])) {
            abort(422, 'Some seats are invalid for this event.');
        }

        $result = app(SeatService::class)->holdSeats($eventId, $validSeatIds, optional($request->user())->id);

        return response()->json($result);
    }

    public function checkout(Request $request, int $eventId)
    {
        $validated = $request->validate([
            'seats' => 'required|array|min:1|max:10',
            'seats.*' => 'integer',
            'currency' => 'required|string|size:3',
        ]);

        $userId = optional($request->user())->id;

        return DB::transaction(function () use ($eventId, $validated, $userId) {
            // Confirm locks still active
            $activeLocks = DB::table('seat_locks')
                ->where('event_id', $eventId)
                ->whereIn('seat_id', $validated['seats'])
                ->where('locked_until', '>', now())
                ->lockForUpdate()
                ->get();

            if ($activeLocks->count() !== count($validated['seats'])) {
                abort(409, 'One or more seats are no longer available.');
            }

            // Build Order from server-side pricing
            $pricings = SeatPricing::where('event_id', $eventId)
                ->whereIn('seat_id', $validated['seats'])
                ->get()
                ->keyBy('seat_id');

            $order = Order::create([
                'user_id' => $userId,
                'event_id' => $eventId,
                'status' => 'pending',
                'currency' => strtoupper($validated['currency']),
            ]);

            foreach ($validated['seats'] as $seatId) {
                $p = $pricings[$seatId];
                OrderItem::create([
                    'order_id' => $order->id,
                    'seat_id' => $seatId,
                    'price_cents' => $p->price_cents,
                    'fee_cents' => $p->fee_cents,
                ]);
            }

            $payment = app(PaymentService::class)->createOrUpdatePaymentIntent($order);

            return response()->json([
                'order_id' => $order->id,
                'client_secret' => $payment['client_secret'],
                'expires_at' => $activeLocks->min('locked_until'), // soonest lock expiry
            ]);
        }, 3);
    }
}

Scaling Up for Big On-Sale Moments

During a major release (concert, festival), you may see enormous spikes:

Feature flags: temporarily limit seat holds duration or cap concurrent holds per user/IP.
Queue prioritization: route payment webhooks and finalizeOrder jobs to a high-priority queue.
Read replicas: offload non-critical reads (browse pages) to MySQL replicas; keep writes on primary.
CDN: cache static assets and seat map images at the edge.
Graceful degradation: if broadcasting fails, the core purchase flow still works; the UI can periodically poll availability.

Wrapping Up

By combining Laravel Octane for high-throughput request handling, MySQL transactions for atomic seat allocation, Redis locks to tame contention, and Stripe’s Payment Intents for secure, idempotent payments, you can build a robust ticket booking platform tailored for events, concerts, and travel. Add QR-code e-ticket generation and real-time seat updates for a polished customer experience. Most importantly, make critical state changes transactional, webhook-driven, and idempotent—those patterns will carry you through both regular days and headline on-sales without double bookings or lost tickets.

Building a Reliable Online Ticket Booking Platform with Laravel