01PREVENT
Reduce opportunities for misuse.
Short-lived entry credentials, ticket-state validation, account verification and controlled seat reservations.
01INDEPENDENT PERSONAL PROJECT
Building a
safer ticket
lifecycle.
Rethinking how event ticketing can combine secure admission, fair purchasing, risk investigation and controlled enforcement.
Independent engineering project inspired by Aung Za Bu's live-performance context. Not commissioned, endorsed or officially affiliated with the artist.
PURCHASEADMISSIONINVESTIGATION
02THE PROBLEM
A ticket is more than a QR code.
A secure ticketing product has to consider everything from booking integrity to the moment a person enters an event.
THE STARTING QUESTION
What if ticketing were designed around trust, rather than simply completing a transaction?
The Aung Za Bu performance context became the inspiration for my independent engineering case study.
I explored common challenges in high-demand ticketing: duplicated credentials, purchasing limits, different ticket-issuance channels and decisions about suspicious activity.
01
Ticket misuse
Copied or reused entry credentials
02
Fair access
Multiple accounts and purchase-limit evasion
03
Complex operations
Online, guest, sponsor and offline tickets
04
Accountability
Evidence-based administrative decisions
These are design risks and hypotheses, not verified claims about incidents at Aung Za Bu events.
03SOLUTION APPROACH
Prevent. Detect. Enforce.
Three connected responsibilities, each with its own objective, evidence requirements and safeguards.
02DETECT
Turn signals into reviewable evidence.
Link relevant account and device activity, identify risk patterns and organize findings for human investigation.
03ENFORCE
Make consequential actions deliberate.
Review affected accounts and tickets, confirm the intended impact and record administrator-controlled actions.
Core principleA risk signal is not proof. Detection and enforcement must remain separate responsibilities.
04BOOKING & PAYMENT
Inventory must have one owner.
A booking interface is only trustworthy when the backend protects seat ownership under concurrent requests.
01
Fan selects available seats.
02
Server creates a time-bound reservation.
03
Payment enters its review lifecycle.
04
Approved bookings lead to ticket issuance.
ENGINEERING DECISION
PostgreSQL transactions and locking coordinate competing seat reservations and payment-state transitions.
SEAT SELECTION
SELECTRESERVEREVIEW
LIVE ADMISSION QR
ISSUEDVALIDATEDCHECKED IN
05SECURE ADMISSION
A screenshot should not be the authority.
Online admission relies on short-lived signed credentials and server-side ticket eligibility checks.
Dynamic admission QR
Each credential expires quickly and is validated against the current ticket, booking and seat state.
Flexible holder verification
Guest, sponsor and offline holders can verify with either an identity fragment or an SMS one-time code.
Sensitive personal and payment data is excluded from dynamic QR payloads.
06RISK DETECTION
Detect patterns. Investigate context.
A shared device or related purchasing activity may deserve review, but should not automatically imply abuse.
Linked activity
Related accounts, occurrences and device observations
Purchase-limit signals
Patterns that may indicate circumvention attempts
Reviewable investigation
Supporting timelines, signals and next steps
IMPORTANT DISTINCTION
The configured device-risk enforcement policy currently operates in shadow mode.
INVESTIGATION
ADMINISTRATOR ACTIONS
07CONTROLLED ENFORCEMENT
Human decisions. Recorded outcomes.
An administrator should understand the consequences of an action before executing it.
01Choose targets and actions
02Review the expected impact
03Provide a decision reason
04Confirm and record execution
Supported administrative actions include purchase restrictions, account bans, identifier blocks, booking cancellations and ticket revocations.
08SYSTEM ARCHITECTURE
More than a mobile interface.
The system separates user experiences, application services and transaction-backed data.
CLIENT
React Native + Expo
Fan · Administrator · Checker
APPLICATION
Node.js + Express
Authentication · Commerce · Verification · Risk
DATA
PostgreSQL
Inventory · Ticket state · Audit records
Secure authentication
Hashed credentials, rotating sessions and access controls.
Protected verification data
Encryption and keyed lookups for sensitive holder information.
Transaction-safe workflows
Locks, atomic updates and idempotent operations.
Simplified conceptual architecture—not a deployment or infrastructure diagram.
09ENGINEERING CHALLENGES
Design for things going wrong.
Correct behavior matters most when multiple requests arrive together or a network response is lost.
FAN AReserve seat A6
FAN BReserve seat A6
POSTGRESQL TRANSACTIONOne valid seat owner
AUTOMATED TEST SCENARIOS
01
Seat contention
Multiple fans compete for the same inventory without multiple successful owners.
02
Payment decision races
Concurrent administrative operations must leave payment and ticket state consistent.
03
Retry and recovery
Repeated offline-sale requests must not duplicate a committed sale.
04
Verification conflicts
Competing entry and verification operations must respect the ticket lifecycle.
10THE ENGINEERING TAKEAWAY
Security is a
product-wide
decision.
This project challenged me to think beyond screens and endpoints: inventory ownership, identity, failure recovery, privacy, evidence and the consequences of enforcement decisions.