System Design: Concert Venue Management

Requirements

Functional Requirements:

• Venue operators manage event scheduling with conflict detection across stages and time slots
• Artist booking workflow: promoter submits offer → artist agent accepts/negotiates → contract generation
• Capacity management per event with tiered access zones (GA, VIP, backstage)
• Staff scheduling: assign crew, security, and volunteers to events with role-based requirements
• Real-time venue operations dashboard: occupancy, bar revenue, incident reporting
• Integration with external ticketing platforms (Ticketmaster, Eventbrite) for inventory sync

Non-Functional Requirements:

• Schedule conflict detection must be atomic — two promoters cannot book the same slot simultaneously
• Occupancy counts must be accurate within 5 minutes for safety compliance
• 99.9% uptime for the operational dashboard during live events
• All financial transactions (artist fees, ticket revenue shares) logged for accounting audit
• Multi-venue support with centralized management for venue chains

Scale Estimation

For a venue management company operating 50 venues: 50 venues × 300 events/year × avg 3,000 capacity = 45M attendees/year = ~123k/day. Staff records: 50 venues × 200 staff/event × 300 events = 3M staff-event assignments/year. Ticketing sync: 1,000 events × 3,000 tickets × 2 status updates (sold/scanned) = 6M inventory sync events/year. Real-time occupancy updates: 50 venues × one update every 5 minutes during events = 10 updates/second during peak season.

High-Level Architecture

The platform has a Management Plane (scheduling, booking, contracts) and an Operations Plane (real-time event operations, dashboards, incident management). The Management Plane is a standard CRUD-heavy web application with strong consistency requirements (schedule conflict detection must be atomic). The Operations Plane requires low-latency reads and writes for the live event dashboard.

Schedule conflict detection uses database-level exclusion constraints (PostgreSQL && range overlap with EXCLUDE USING gist) on venue+time ranges. When two promoters attempt to book overlapping slots concurrently, the constraint violation causes one to fail atomically — no application-level locking needed. This approach is simple, reliable, and leverages the database's built-in concurrency control.

External ticketing integration is handled by a Sync Service that maintains bi-directional inventory state with Ticketmaster and Eventbrite APIs. The service uses webhook receivers for incoming inventory events (ticket sold on Ticketmaster) and a polling fallback for platforms without webhooks. Inventory discrepancies are detected by periodic reconciliation jobs and surfaced to venue operations staff.

Core Components

Event Scheduling Service

Manages the venue calendar with conflict detection at the database level. Events have: venue_id, stage_id, time_range TSTZRANGE, setup_time_before INTERVAL, teardown_time_after INTERVAL. The scheduling service computes the total occupied range (event + buffer times) and attempts an INSERT that will fail on the exclusion constraint if any overlap exists. This provides serializable conflict detection without explicit locking. Multi-stage venues have per-stage calendars, and exclusive-use events lock all stages.

Artist Booking & Contract Service

Manages the negotiation workflow as a state machine: draft → offer_sent → counter_offer → accepted → contracted → cancelled. Offer terms (fee, rider requirements, technical specs) are versioned JSONB documents. Contract generation uses a template engine substituting accepted terms into a standard legal template, producing a PDF stored in S3. Digital signature integration (DocuSign or similar) tracks signature status. All financial terms are extracted and synced to the accounting system as a booking record.

Real-Time Operations Dashboard

A WebSocket-based dashboard for venue operations staff. Occupancy counts are updated via an entry management system API (turnstile counts or scanning app data) pushed to Redis Pub/Sub and fanned out to dashboard connections. Bar and merchandise revenue is synced from POS system webhooks in near-real-time. Incident reports are submitted by staff via a mobile app and broadcast to all operational staff connected to the same venue session. A Redis TimeSeries database stores occupancy history for compliance reporting.

Database Design

Core tables in PostgreSQL: venues (venue_id, name, capacity, address, timezone), stages (stage_id, venue_id, capacity, stage_type), events (event_id, venue_id, stage_id, promoter_id, time_range TSTZRANGE, status ENUM). The exclusion constraint: EXCLUDE USING gist (stage_id WITH =, time_range WITH &&) WHERE (status != 'cancelled'). Artist bookings: bookings (booking_id, event_id, artist_id, fee, status ENUM, contract_s3_key). Staff assignments: staff_assignments (assignment_id, event_id, staff_id, role, shift_range TSTZRANGE).

Operations data: occupancy_readings (venue_id, event_id, timestamp, count) stored in TimescaleDB for efficient time-series queries. incidents (incident_id, event_id, type, description, reported_by, reported_at, resolved_at). pos_transactions (transaction_id, venue_id, event_id, amount, category, timestamp) synced from POS systems. A materialized view aggregates revenue by event, refreshed every 5 minutes during live events.

API Design

POST /api/v1/venues/{venueId}/events — creates a new event and checks schedule conflicts atomically via exclusion constraint.

PUT /api/v1/bookings/{bookingId}/accept — artist agent accepts booking terms; triggers contract generation.

POST /api/v1/events/{eventId}/occupancy — operations endpoint to push a real-time occupancy reading.

GET /api/v1/events/{eventId}/dashboard — returns aggregated real-time dashboard data (occupancy, revenue, incidents).

Scaling & Bottlenecks

The operational dashboard is the main scaling concern during live events. A venue chain running 20 simultaneous events on a Saturday night has 20 active dashboard sessions with real-time data pushes. Redis Pub/Sub with per-event channels handles this comfortably at this scale. The bottleneck arrives when a single popular venue has 500+ operations staff watching the dashboard — at that point, fan-out from a single Redis channel to 500 WebSocket connections requires a backplane with sufficient throughput, handled by using multiple WebSocket gateway instances subscribing to the same Redis channel.

Ticketing sync is an eventual consistency problem: ticket inventory on external platforms may lag by 30-60 seconds. For oversell prevention, the venue's internal inventory counter is authoritative — sales through the external platform are limited to the quota assigned to that platform, not the full remaining inventory. A reconciliation job at sale close confirms total sold across all channels doesn't exceed capacity.

Key Trade-offs

• Database exclusion constraints vs. application-level locks: Database constraints are simpler and eliminate race conditions without additional infrastructure, but PostgreSQL-specific syntax limits portability; application-level distributed locks (Redis) are more portable but add latency and failure modes.
• Tight vs. loose integration with external ticketing: Deep API integration gives real-time inventory sync but creates a dependency on external platform availability; a looser quota-allocation model is more resilient but risks leaving inventory unsold if quota estimates are wrong.
• Real-time vs. batch staff scheduling: Real-time scheduling change notifications are critical for live events but complex to implement; batch schedule distribution before the event day is simpler but inflexible for last-minute changes.
• Centralized vs. per-venue databases: A centralized multi-tenant database simplifies cross-venue reporting but creates noisy-neighbor risks; per-venue databases provide isolation but complicate cross-chain analytics.