Event Hub API
Evolved an event ticketing API into a production-ready platform with role-based security, overbooking protection, cached event listings, containerized infrastructure, and post-purchase confirmation events.
Overview
Built and hardened a REST API for events, participants, and ticket purchases, moving from a CRUD-oriented service to a robust, secure, and operationally ready backend.
Problem
The initial API foundation covered core domain entities, but it lacked production-grade safeguards. It needed clear role-based access control, safe concurrent ticket purchasing, better read performance on event listings, consistent containerized deployment, and a post-purchase integration flow.
Constraints
- Security rules had to enforce strict role boundaries: only ADMIN users can create or delete events, while USER accounts can purchase tickets.
- The purchase flow had to avoid overbooking when multiple users attempt to buy the last available ticket simultaneously.
- Event listing endpoints needed faster response times without sacrificing data consistency for frequently read data.
- The full stack needed to be runnable in a reproducible environment with Docker and Docker Compose, including PostgreSQL.
Approach
Implemented a layered production-hardening strategy: Spring Security for authentication and authorization, transactional concurrency control on ticket purchases, caching for event listing reads, containerized runtime with Docker Compose, and an integration hook that emits a confirmation event after successful purchases.
Key Decisions
Use Spring Security with role-based authorization on endpoint boundaries
Security needed to be explicit and enforceable in the API contract. Endpoint-level role checks make ownership clear, reduce accidental privilege exposure, and align with the product rule that ADMIN and USER actions differ.
- Single shared role with business checks spread across services
- No authentication in API layer, relying only on network boundaries
Apply pessimistic locking in the purchase transaction to prevent overbooking
Ticket inventory is a contention hotspot. Row-level locking on the relevant event or inventory record guarantees one successful transaction at a time for the final seats, preventing race conditions that could oversell tickets.
- Optimistic locking with retry loops
- Queue-based reservation workflow
Cache event listing responses to reduce repeated database reads
Event listings are read-heavy and update less frequently than they are queried. Caching this path improves responsiveness and lowers PostgreSQL load while preserving the source of truth in the database.
- No cache and horizontal scaling only
- Cache only at the API gateway or CDN layer
Emit a post-purchase confirmation event as an integration simulation
Purchase completion should trigger side effects without coupling the checkout transaction to external delivery channels. Emitting a domain event (logged or mock-integrated) keeps the flow extensible for future email or notification providers.
- Send confirmation synchronously inside the purchase transaction
- Skip integration signaling until a later release
Tech Stack
- Java 21
- Spring Boot 4
- Spring Web MVC
- Spring Security
- Spring Data JPA
- Jakarta Bean Validation
- Flyway
- PostgreSQL
- Spring Cache
- Springdoc OpenAPI (Swagger)
- Docker
- Docker Compose
- Maven
Result & Impact
The API moved from a functional prototype to a production-oriented service with clearer access policies, safer transactional behavior under concurrency, better read-path performance, and a cleaner path for asynchronous integrations after purchase completion.
Learnings
- Role boundaries are most reliable when encoded directly at API entry points.
- Inventory-like domains require explicit concurrency strategy early, not as a post-incident fix.
- Caching is most effective when applied to read-heavy routes with clear invalidation rules.
- Containerized local environments reduce setup friction and improve delivery consistency.
- Event-driven integration points help keep transactional code focused and easier to evolve.
Security and Access Model
The security model enforces clear responsibilities across actors. Administrative event lifecycle operations are restricted to ADMIN, while ticket acquisition flows are scoped to USER permissions.
This separation keeps authorization intent explicit and reduces ambiguity in service-level business logic.
Concurrency and Purchase Reliability
The critical purchase path applies transactional locking to protect ticket inventory during concurrent requests. This prevents two buyers from successfully reserving the same final ticket in high-contention scenarios.
By handling concurrency at the persistence boundary, the API maintains domain consistency without leaking race-condition complexity to clients.
Operational Readiness
A cache layer improves responsiveness for event listing endpoints and reduces repetitive database load. The project is also packaged with Dockerfile and docker-compose, enabling reproducible local and deployment-ready environments with PostgreSQL included.
After a successful purchase, the system emits a confirmation event (log/mock integration), establishing a clean extension point for future email delivery providers.