Barby - Live Music Venue

Barby Tel Aviv is the largest and most complex system I have built so far.

It started as a modernization project for a live music venue, but grew into a complete production platform used for ticket sales, show management, customer support, gift cards, analytics, CRM operations, and internal back-office workflows.

The platform handles around 60k page views per day and around 20k orders per month, while also working with historical operational data going back to 2009.

This was not a demo or a simple marketing website. It became a real business-critical platform used by customers, staff, production teams, and management.

Basic Overview

The system has two main sides:

The public website needed to be simple and fast for customers.

The internal system needed to handle the real complexity behind the scenes: different sale types, payment validation, ticket quantities, secret links, gift cards, order recovery, historical records, and operational debugging.

What Customers Can Do

Customers can use the public site to:

• browse upcoming shows
• search events
• open a specific show page
• select ticket quantity
• purchase tickets
• pay with credit card or Google Pay
• receive an email confirmation
• download tickets as a PDF
• access their personal account area
• view order history
• update details
• buy gift cards
• use secret ticket links when available
• contact support through the chatbot

What Staff Can Do

The back-office system supports internal operations such as:

• create and update shows
• manage dates, times, prices, and images
• control ticket sale states
• manage presales and regular sales
• create secret ticket links
• search orders
• inspect customer records
• debug failed or missing orders
• manage gift cards
• monitor live sales
• reports exports
• work with historical data from old systems
• support customers quickly without touching the database manually

Public Website and User Flow

The public website was built around the actual customer journey.

A user can discover a show, open the event page, select ticket quantity, fill in personal details, pay through the payment provider, and receive a confirmation email with a ticket PDF.

The same system also supports more complex flows like gift cards, secret ticket links, presale access, sold-out states, waiting lists, and account-based order history.

Screens and Flow

Homepage and Show Discovery

The homepage includes the main Barby navigation, a large visual show carousel, featured events, show search, and direct access to the account area, gift cards, contact, and support.

This screen represents the customer-facing entrance to the platform. It needed to be visual, fast, and simple while still being connected to dynamic show data from the backend.

Show Page and Ticket State

Each show page displays event information, image, date, door opening time, ticket type, price, quantity selector, and artist description.

The complexity behind this page is much larger than what the user sees. The backend decides which tickets are available, which states should be shown, whether the event is sold out, whether presale is still available, whether regular sale is open, and whether secret links should override the public state.

Ticket Purchase Form

The purchase form is where most of the customer-facing logic comes together.

It includes:

• show date
• door opening time
• countdown timer
• ticket type
• ticket price
• quantity selection
• customer name
• ID field
• phone
• email
• gift card option
• SMS or email delivery options
• terms confirmation

This screen needed to support both simple and complex ticket flows while staying clear enough for regular customers.

Payment Page

The checkout flow connects to the payment provider.

The payment screen supports:

• Google Pay
• credit card payment
• total amount calculation
• payment confirmation
• redirection back to Barby after payment

Payment integration was one of the most sensitive parts of the system because successful payment must result in correct order creation, ticket creation, PDF generation, and email delivery.

Successful Order Page

After payment, the customer is redirected to a success page.

This page confirms that the order was received successfully and explains that the ticket PDF was sent by email.

It also shows the order number and a short waiting indication while the system validates and prepares the order confirmation.

Ticket Confirmation Email

The order confirmation also appears clearly in the customer’s inbox with the order number and show details.

This makes it easier for customers to find their tickets later, especially on the day of the event.

After a successful order, the system sends a confirmation email.

The email includes:

• order number
• show name
• show date
• door opening time
• ticket instructions
• link to download tickets
• attached ticket PDF

This part is critical because the email is the customer’s main proof of purchase and ticket access point.

Waiting List State

When a show is sold out, the system can show a waiting list state. Customers can register for the waiting list by providing their name and contact details. This allows the team to manage demand and potentially offer tickets to waiting customers if more become available.

Customer Account Area

The account area allows customers to see their personal details and access important actions.

It includes:

• customer name
• email
• phone number
• order number
• gift card access
• order history
• password reset

This was important because customers often need to recover tickets, check previous orders, or update account-related details.

Chatbot and Customer Support

The chatbot gives customers a quick support path without needing to immediately contact staff.

It can guide users toward common actions such as account help, gift card questions, and payment-method questions. In the wider system, support flows connect to order lookup and customer-service logic.

This reduced manual support pressure and made common questions easier to answer.

Ticketing Logic

The ticketing system supports many real-world ticket scenarios.

A show can have:

• regular tickets
• presale tickets
• early-bird prices
• secret ticket links
• limited ticket allocations
• sold-out states
• presale sold out while regular tickets remain available
• regular tickets sold out while secret links are still active
• different price tiers
• different ticket quantities per customer
• internal-only ticket configurations
• waiting lists
• closed sales
• standing or seated show types

This required a backend that could calculate the correct ticket state for every request.

The customer should only see a simple result: buy, sold out, registration, waiting list, or unavailable.

The backend handles the complexity.

Presale and Regular Sale States

One of the harder parts was supporting separate sale phases.

A show might be:

This means “sold out” is not always one simple boolean.

The system has to understand what kind of ticket is sold out, what sale phase is active, and whether the customer is using a special access link.

Secret Ticket Links

The system supports secret ticket links for private sales and special access flows.

A secret link can define:

• a specific show
• a specific ticket price
• a specific ticket quantity
• a limited allocation
• private access outside the normal public sale
• campaign-specific links
• presale access
• guest or partner access

This lets the team sell tickets flexibly without exposing every ticket type publicly.

For example, the public page can show a normal price or sold-out state, while a secret link can still allow a selected group to buy a limited number of tickets at a specific price.

Gift Card System

The platform also includes a gift card system.

Users can purchase a gift card for someone else, and the system handles the payment, order creation, gift card record, and delivery flow.

The gift card flow required separate handling because it behaves differently from a normal show ticket.

It includes:

• buyer details
• recipient details
• gift card amount
• payment validation
• gift card creation
• gift card transaction record
• email delivery
• order history connection
• internal support visibility

Gift cards also needed to integrate with the rest of the customer account and order infrastructure.

Order Management

The system handles around 20k orders per month.

Order management includes:

• order creation
• payment validation
• ticket generation
• PDF generation
• confirmation emails
• barcode references
• customer records
• ticket quantities
• refunds or invalid states
• failed payment handling
• duplicate callback protection
• old order lookup
• internal debugging

Orders are one of the most important parts of the system because every mistake directly affects customers and support.

Historical Data Since 2009

The platform works with historical data going back to 2009.

This means the system could not assume every order or customer record was created by the new platform.

It needed to work with:

• old SQL records
• newer MongoDB records
• old customer formats
• inconsistent date formats
• historical show data
• legacy order IDs
• older ticket structures
• newer payment-provider records

This made the back office much more complex than a clean new admin panel.

Back Office and CRM

The back office is the internal system used by the Barby team.

It includes:

• show management
• user management
• customer lookup
• order search
• ticket search
• gift card management
• CRM operations
• live analytics
• sales monitoring
• historical data lookup
• support workflows
• internal reporting
• operational debugging

The goal was to let non-technical staff manage daily operations without needing direct database access.

Show Management

The show management area allows the team to control the full lifecycle of a show.

Staff can manage:

• show title
• artist information
• show image
• show date
• door opening time
• public visibility
• ticket price
• ticket types
• ticket limits
• presale availability
• sold-out state
• secret links
• waiting-list state
• show description
• active or inactive status

Every show can have different business rules, so the system had to be flexible.

Search and Support Tools

A major part of the internal system is fast order and customer lookup.

Staff can search by:

• order ID
• customer name
• email
• phone number
• show ID
• show name
• ticket barcode
• payment reference
• gift card reference

This allows the support team to quickly answer real customer questions like:

• “I paid but did not get my ticket”
• “I entered the wrong email”
• “I lost my ticket”
• “Can you resend the PDF”
• “My gift card did not arrive”
• “I bought tickets for someone else”

Payment Integrations

The platform integrates with payment providers such as PayPlus and Tranzila.

The payment system handles:

• payment initialization
• payment page redirection
• Google Pay support
• credit card payment
• payment callback validation
• success page validation
• failed payment handling
• duplicate callback handling
• ticket creation after payment
• gift card creation after payment
• order confirmation email
• PDF attachment delivery

Payment handling required defensive logic because payment providers can send callbacks more than once, fail mid-flow, or return data in formats that need validation.

Email and PDF Ticket Delivery

After a successful order, the system generates and sends a confirmation email.

The email includes:

• order number
• show name
• show date
• door opening time
• instructions
• ticket link
• attached PDF

The PDF ticket is part of the order flow, not a manual step.

This means the system needs to connect payment success, database order records, ticket data, PDF generation, and email delivery into one reliable flow.

Live Analytics

The internal platform includes live analytics and operational visibility.

This helps the team monitor:

• current ticket sales
• active shows
• demand for specific events
• order volume
• sales performance
• ticket availability
• customer activity
• operational problems

This turned the system from a simple admin panel into a daily operations platform.

Data Processing

The system processes data from multiple sources.

Some records come from MongoDB. Some come from SQL. Some come from payment providers. Some are generated internally.

This required careful handling of:

• mixed ID formats
• old date formats
• show IDs
• order IDs
• ticket IDs
• barcode references
• payment references
• customer records
• gift card records
• CSV exports
• Excel exports
• aggregation queries
• server-side filtering

For large datasets, the system needed backend-side queries and aggregation instead of loading everything into the frontend.

Security

The internal system includes protected access and backend validation.

Security work included:

• JWT-based access control
• protected admin routes
• restricted order lookup
• payment callback validation
• CORS configuration
• backend input checks
• sensitive customer data protection
• controlled internal APIs

Because the system handles real customer data, tickets, payments, and internal operations, security and access control were important parts of the architecture.

Scale

Approximate production scale:

The system had to remain stable during normal traffic, high-demand shows, ticket drops, and operational peaks.

Main Challenges

Complex Ticket States

The biggest challenge was that ticket availability is not simple.

A show can be open, closed, sold out, partially sold out, open only for presale, open only through secret links, or visible only as a waiting list.

The frontend needed to show the correct state clearly, while the backend handled the real rules.

Payment Reliability

Payment flows had to be reliable because every successful payment must result in the correct ticket or gift card.

The system needed to prevent:

• duplicate orders
• missing tickets
• failed gift cards
• broken success pages
• incorrect customer records
• unsent confirmation emails

Legacy Integration

The platform had to work with older infrastructure and historical data.

This meant building modern workflows without breaking existing records or long-running operational logic.

Operational Use

The system is used by real staff, not only customers.

That means the back office had to support practical daily work:

• fixing customer issues
• finding orders quickly
• checking payments
• resending tickets
• managing show changes
• debugging edge cases
• monitoring live sales

What This Project Shows

This project demonstrates:

• full-stack ownership
• production system design
• public website development
• backend API architecture
• payment integration
• database modeling
• legacy system integration
• CRM and back-office design
• operational tooling
• live analytics
• customer-support workflows
• performance-aware data handling
• long-term maintainability

Why This Project Matters

This is my main flagship project because it shows more than writing code.

It shows the ability to understand a real business, build around existing constraints, support internal teams, handle production problems, and create software that people actually depend on.

The project connected customer-facing flows, internal operations, payment systems, historical data, and business logic into one working platform.

Links