Central e-ticketing and box-office platform

The problem

Ticket sales depended largely on the box office. Advance sales were limited, queues grew on public holidays, and sales and entry data from different venues could not be brought together.

My role

Sole developer: platform architecture, the shared API layer, database design, payment integration, the box-office application and go-live.

The solution

A single ticketing platform now serves every venue. Visitors can buy online, at the box office or through their travel agency. Because every channel uses the same central API, a ticket validates the same way at every turnstile and handheld terminal, whichever channel sold it.

Online payments go through a bank virtual-POS integration. During sudden peaks such as a holiday morning, frequently read data is served from cache and the database is hit only when really needed. The box-office app runs on the same infrastructure, so end-of-day reports cover all channels together.

Outcome

• Sales, payments and entries are tracked from a single source; part of the peak-time queue moved to online sales.

The hard parts and the decisions I made

A single point of validation

As sales channels multiplied, letting each channel carry its own rules would sooner or later mean two channels deciding differently. I connected every channel to the same central API: ticket rules live in one place, and the website, box office, agencies, turnstiles and handhelds all get the same answer to the same question.

A holiday morning

A ticketing system is judged at its busiest hour, not on an ordinary day. Data that is read often but changes rarely, such as venues, sessions and prices, is served from an in-memory cache, leaving the database for the work that really needs it: sales and validation. I also kept the validation query lean enough to touch a single record.

A payment left half-done

If a payment succeeds at the bank but the connection drops before the ticket is issued, the visitor has paid without getting a ticket. I designed orders, payments and ticket issuing as clearly tracked states, so an unfinished transaction is never lost and it is always clear which step it stopped at.

Reports from one source

The box-office app runs on the same infrastructure, so end-of-day reconciliation does not mean stitching together outputs from separate systems.

What I learned

Most design decisions came down to one question: “What happens at opening time on a holiday morning?” Every small slowdown that goes unnoticed on a normal day turns into a queue at that hour.

Technologies

• Backend: C#, .NET, shared REST API layer with role-based authorization
• Database: SQL Server
• Performance: In-memory cache layer
• Payments: Bank virtual-POS integration
• Integrations: Turnstiles and handhelds, box office, agency portal, e-Devlet and KPS identity checks
• Interfaces: Web (online sales), box-office application