Event Management Microservices Platform

A service-oriented web platform for managing events, event packages and ticket sales — built as a set of independent web services (SOA / microservices).

Portfolio note: this project focuses on clean service boundaries, REST APIs, role-based access control, and cross-service communication.

---

Highlights

• SOA / microservices architecture: separate services for Events, Clients, and Identity Management (Auth/Roles).
• Ticketing business rules (capacity limits, package constraints, no overselling).
• Role-based access: admin, owner-event, client.
• Search & filtering + pagination via query params (e.g., name/location/available tickets).
• Polyglot persistence:
  • SQL DB for events / packages / tickets
  • MongoDB for client profiles & purchased tickets
• Inter-service validation (chain pattern): Client service calls Events service to validate tickets / enrich ticket info.

---

Architecture (high-level)

Frontend Web App
→ calls IDM/Auth API for login/logout
→ calls Event Service API and Client Service API for data operations
Both Event & Client services validate session tokens using the IDM/Auth service.

Services

• IDM Service (Identity Management)
  • Users + roles (admin/owner-event/client)
  • Authentication & authorization support
• Event Service
  • Events, event packages, tickets
  • Capacity constraints + filtering/pagination
• Client Service
  • Client profiles stored in MongoDB (optional fields supported)
  • Stores ticket lists (short or detailed form)
  • Validates tickets by calling the Event service
• Frontend
  • UI for browsing events/packages, buying tickets, and role-based management

---

Core domain rules (implemented)

• Accounts are created by an admin (manager/owner-event/client).
• An event owner can fully manage only the events/packages they own.
• You cannot oversell tickets beyond configured capacity.
• A package capacity is limited by the minimum available capacity across its included events.
• Capacity must exist (no selling for events/packages without configured seats).
• Capacity cannot be edited if at least one ticket was already sold for that event/package.

---

API (example endpoints)

Actual routes may vary slightly depending on implementation.

Event Service

• GET /api/event-manager/events/{id}
• GET /api/event-manager/event-packets/{id}
• GET /api/event-manager/tickets/{code}
• Navigation:
  • /api/event-manager/events/{id}/event-packets
  • /api/event-manager/event-packets/{id}/events
  • /api/event-manager/events/{id}/tickets/{id}
  • /api/event-manager/event-packets/{id}/tickets/{id}

Filtering / pagination examples:

• /api/event-manager/events?location=...
• /api/event-manager/events?name=... (partial match)
• /api/event-manager/event-packets?page=...&items_per_page=...
• /api/event-manager/event-packets?available_tickets=...

Client Service

• CRUD for client documents (MongoDB) + ticket list endpoints
• Validates tickets by calling Event Service before processing

IDM/Auth Service

• Login/logout + token validation
• Role-based authorization helpers used by other services

---

Tech stack (typical)

• Backend: Java + Spring Boot, REST APIs
• Databases: SQL (events/packages/tickets, users), MongoDB (clients)
• Frontend: React + TypeScript
• Docs/Testing: OpenAPI/Swagger, Postman

---

Project structure

• backend/java-spring-boot/eventmanager/ – Event Service
• backend/java-spring-boot/idm_service/ – IDM/Auth Service
• backend/java-spring-boot/client_service/ – Client Service (MongoDB)
• frontend/ – React UI

---