Zulu - Enterprise Ticketing Platform

HackLoad 2025 hackathon project by Team Zulu. A high-performance, scalable ticketing system designed to handle massive concurrent loads and complex booking scenarios.

The Zulu ticketing platform addresses the challenge of selling tickets for large-scale events (100K+ seats) with thousands of concurrent users.

System Architecture

Core Components

┌─────────────────────────────────────────────────────────────┐
│                    Zulu Ticketing Platform                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────┐    ┌─────────────────────────────────┐ │
│  │   Billetter     │    │      External Provider         │ │
│  │     API         │◄───┤      Integration              │ │
│  │                 │    │                               │ │
│  │ • Event Mgmt    │    │ • EventProviderService        │ │
│  │ • Seat Booking  │    │ • Order Management           │ │
│  │ • Payment Flow  │    │ • Place Reservations         │ │
│  │ • Real-time     │    │ • External API Wrapper       │ │
│  └─────────────────┘    └─────────────────────────────────┘ │
│           │                              │                  │
│           ▼                              ▼                  │
│  ┌─────────────────────────────────────────────────────────┐ │
│  │            Service Architecture                         │ │
│  │                                                         │ │
│  │ ┌─────────────┐  ┌──────────────┐  ┌─────────────────┐ │ │
│  │ │ Billetter   │  │ EventProvider│  │   Shared Types  │ │ │
│  │ │ Service     │  │   Service    │  │  & Utilities   │ │ │
│  │ │ (Abstract)  │  │              │  │                 │ │ │
│  │ └─────────────┘  └──────────────┘  └─────────────────┘ │ │
│  │        │                │                    │         │ │
│  │        ▼                ▼                    ▼         │ │
│  │ ┌─────────────┐  ┌──────────────┐  ┌─────────────────┐ │ │
│  │ │InMemoryImpl │  │   HTTP       │  │    Types &      │ │ │
│  │ │             │  │   Client     │  │   Validation    │ │ │
│  │ │• 100K seats │  │              │  │                 │ │ │
│  │ │• Atomic ops │  │• Error       │  │• TypeScript     │ │ │
│  │ │• Concurrency│  │  handling    │  │  definitions    │ │ │
│  │ └─────────────┘  └──────────────┘  └─────────────────┘ │ │
│  └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘

Key Architectural Decisions

1. Service-Based Design: Clear separation between core ticketing logic and external integrations
2. Abstract Service Layer: Enables future database backends without API changes
3. Comprehensive Testing: Stress tests validate real-world performance requirements

Implementation Status

✅ Completed Components

• Project Structure: Complete service-based architecture
• External API Wrapper: EventProviderService with full error handling
• Billetter Service: Abstract Billetter Service class and dummy In-Memory implementation for testing
• Event Provider Service: External API wrapper according to OpenAPI specification
• API Endpoints: Complete Fastify route implementation according to OpenAPI specification
• Testing Framework: Unit, integration, and stress test suites
• Type Safety: Comprehensive TypeScript definitions

Performance Targets

• Event Scale: 100,000+ seats per event
• Concurrent Users: 10,000 simultaneous connections
• Sellability: 80% of tickets sold within 4 hours
• Response Time: Sub-100ms for seat operations
• Availability: 99.9% uptime during peak sales

Architecture Decisions & Development Journey

Initial Blockchain Exploration

We initially set out to explore blockchain technology for our ticketing implementation, despite knowing that specialized frameworks would likely outperform blockchain solutions for high-load scenarios. We wanted to see the actual difference in performance metrics comparing with other implementations delivered at the hackathin.

Our hypothesis was that blockchain's advantages in peer-to-peer networking could justify its use as the network scales with more participants.

Part 1: Solana Investigation

Our first attempt involved spinning up a private Solana cluster. However, we quickly identified concerns with Solana's architectural design, particularly its history of denial-of-service incidents that have not affected more established networks like Bitcoin and Ethereum. This led us to explore alternative blockchain platforms.

Part 2: Hyperledger Fabric Challenges

We then investigated Hyperledger Fabric as a permissioned blockchain solution, which appeared ideal for our enterprise ticketing requirements. However, deployment proved more complex than anticipated:

• Enterprise Complexity: The platform requires extensive technical expertise beyond typical public blockchain setup
• Limited Ecosystem: Compared to Ethereum, the documentation was sparse and community support minimal
• Tooling Issues: Promising tools like "minifabric" (single-config cluster deployment) were abandoned, while alternatives like "microfabric" failed to work in our local environment

Part 3: Application-Specific Blockchain Exploration

We also evaluated application-specific blockchain frameworks like Tendermint and CosmosSDK. While promising, these platforms lack JavaScript support for custom business logic, requiring Go expertise we didn't possess within our time constraints.

Pivot to AI-Assisted Development

Recognizing time limitations for blockchain setup, we pivoted to explore AI-assisted development methodologies, using this hackathon as an opportunity to experiment with modern development practices.

Development Methodology

• PRD-Driven Development: Used detailed Product Requirements Documents to guide implementation
• AI-Assisted TDD: Experimented with Test-Driven Development enhanced by AI coding assistants
• Tools: Leveraged OpenCode and Claude Code for Node.js API development according to specifications

Implementation Results

This approach enabled us to successfully implement:

1. Billetter API: Complete ticketing service with event management, seat reservation, and payment integration
2. Event Provider Service: External API wrapper for distributed ticketing networks
3. Comprehensive Testing: Unit, integration, and stress tests validating performance requirements
4. Production-Ready Architecture: Service-based design supporting enterprise-scale loads

Development Log & Lessons Learned

Technical Achievements

• Rapid Prototyping: AI-assisted development significantly accelerated initial implementation
• Test Coverage: Achieved comprehensive testing including performance validation
• Architecture Quality: Delivered production-ready service abstractions and patterns
• Specification Compliance: Full adherence to OpenAPI requirements

Key Insights

• Blockchain Complexity: Enterprise blockchain deployment requires significant time investment and specialized expertise
• AI Development: Modern AI tools can effectively accelerate development when combined with solid architectural planning
• PRD-Driven Approach: Detailed requirements documents enable more focused and effective development
• Testing First: Stress test development alongside core functionality ensures performance targets are met

Future Blockchain Considerations

While we didn't complete blockchain implementation within the hackathon timeframe, we identified promising paths for future exploration:

• CosmosSDK: Could be ideal for application-specific ticketing chains with Go/Rust development resources
• Hyperledger Fabric: Remains viable for enterprise deployments with proper setup expertise
• Hybrid Approach: Traditional high-performance core with blockchain integration for specific use cases (audit trails, multi-party coordination)

---

Team Zulu - HackLoad 2025

• Denis Perov - https://github.com/imajus
• Sanjar Bishmanov