Reserve seats without the double-booking.
Enzo is a reservation and booking platform for high-concurrency inventory — starting with events and seats, designed to grow into tickets, appointments, and other limited-capacity experiences.
Users browse events and shows, select available seats, place temporary holds, and confirm bookings. Enzo’s job is to turn those competing reservation attempts into a consistent outcome: the same inventory cannot be successfully reserved twice. That reliability is the product’s core value — especially under concurrent load.
The planned stack is a Spring Boot backend on Java 25 with PostgreSQL and Flyway, a React + TypeScript frontend, and local services via Docker Compose. AWS services and Infrastructure as Code come later; local AWS emulation is planned with Floci. The repository is a monorepo (apps/, infra/, docs/) and is currently a scaffold only.
| Area | What the project provides |
|---|---|
| Catalog | Planned support for events, venues, and shows as the browseable inventory surface. |
| Inventory | Planned seat and section inventory with availability and pricing models. |
| Holds | Planned temporary reservation holds with expiration so seats are not locked indefinitely. |
| Concurrency | Explicit design goal: competing requests for the same seat yield exactly one successful reservation. |
| Bookings | Planned checkout, confirmation, cancellations, and refunds after a hold converts. |
| Frontend | Planned React + TypeScript UI for browsing, seat selection, countdown holds, and checkout. |
| Local development | Planned Docker Compose environment for supporting services such as PostgreSQL. |
| Cloud & IaC | Gradual AWS adoption (ECS/Fargate, RDS, S3, SQS, secrets) with Terraform or AWS CDK, plus Floci for local emulation. |
Note
Pre-alpha / v0.0.1. This repository is an empty monorepo scaffold. There is no runnable Spring Boot app, no frontend app, no migrations, and no reservation logic yet. Sections below describe the intended product and architecture; treat completed work as none until roadmap items are checked off.
Users browse an event, select a show, view available seats, place a temporary hold, check out, and confirm a booking.
Under concurrency, multiple users may attempt the same seat at once. The intended runtime behavior is that holds and confirmation use concurrency control so only one reservation succeeds; others fail cleanly rather than overselling. Hold expiration should release unused inventory back to availability. Exact locking, isolation, and idempotency strategies are not implemented yet.
Conventions are not established in code yet. The intended boundaries are: HTTP API in Spring Boot, domain logic for holds and bookings, relational persistence in PostgreSQL via Spring Data JPA/JDBC with Flyway-owned schema, and infrastructure defined under infra/ for local and cloud environments.
| Layer | Technology |
|---|---|
| Language (backend) | Java 25 |
| Backend framework | Spring Boot (planned) |
| Build | Maven |
| Persistence | PostgreSQL, Flyway, Spring Data JPA / JDBC (planned) |
| Frontend | React, TypeScript (planned) |
| Local services | Docker, Docker Compose |
| Cloud | AWS (ECS/Fargate, RDS, S3, SQS, secrets — planned) |
| Local AWS emulation | Floci (planned) |
| Infrastructure as Code | Terraform or AWS CDK (planned) |
enzo/
├── apps/
│ ├── backend/
│ │ └── backend/ # Java / Maven Spring Boot API
│ │ ├── src/
│ │ ├── pom.xml
│ │ └── mvnw
│ └── frontend/ # React / TypeScript UI (scaffold)
│ ├── src/
│ └── package.json
├── infra/
│ ├── docker-compose.yml
│ └── terraform/ # IaC (placeholder)
├── docs/
│ └── assets/
│ └── enzo-logo.png # Project logo
└── README.md
Prerequisites will firm up as the apps are initialized. Expected baseline:
- macOS, Linux, or Windows with a container runtime
- Docker and Docker Compose
- JDK 25 (for the backend, once Spring Boot is added)
- Node.js and npm (for the frontend, once React is added)
- Git and optionally GitHub CLI
There is no production deployment yet. Local development will center on Docker Compose for PostgreSQL and related services; AWS and Floci are roadmap items.
- Clone the repository:
git clone https://github.com/aneeshpatne/enzo.git
cd enzo-
Inspect the monorepo layout under
apps/,infra/, anddocs/. -
When supporting services are configured, start them with:
docker compose -f infra/docker-compose.yml up- When the Spring Boot app exists, run it from the backend module:
cd apps/backend/backend
./mvnw spring-boot:runImportant
The backend Maven Wrapper, Spring Boot application, frontend toolchain, and Compose services are not wired up yet. The commands above are the intended workflow; they will fail until those pieces are added.
No test suite exists yet.
Once the backend is initialized, the expected command-line entry point is:
cd apps/backend/backend
./mvnw testFrontend and concurrency/load tests will be documented when those suites exist. Early reservation work should include concurrent reservation tests as a first-class goal.
- Initialize Spring Boot backend
- Configure PostgreSQL
- Add database migrations
- Establish initial domain model
- Add Docker Compose development environment
- Events and shows
- Seat inventory
- Seat availability
- Temporary reservation holds
- Hold expiration
- Booking confirmation
- Concurrent reservation tests
- Event browsing
- Seat selection
- Reservation countdown
- Checkout flow
- Booking history
- Authentication
- Idempotent APIs
- Caching
- Async jobs
- Metrics and tracing
- Load testing
- AWS deployment environment
- Container deployment with ECS/Fargate
- RDS PostgreSQL
- S3 integration
- SQS-based async processing
- Secrets management
- Infrastructure as Code
- Local AWS emulation with Floci
License is TBD. No license file is published yet; do not assume redistribution or reuse rights until one is chosen and linked here.
Pre-alpha scaffolding for concurrent reservations — Java, Spring Boot, and careful inventory semantics ahead.