Skip to main content
← Selected work

Distributed Event Booking Platform

Bookaroo

Event bookings across independent services, with consistency when things go wrong.

Software Engineer · Team project

BOOKBOOKBOOKTICKET · CONFIRMEDSEAT 12B ✓PAID · EMAILEDKONGBOOKEVENTEVENTSPostgreSQL · S3EVENTSPostgreSQL · S3BILLINGStripeBILLINGStripeTICKETSPostgreSQLTICKETSPostgreSQLNOTIFYOutSystems · SESNOTIFYOutSystems · SESBOOKING SITEGATEWAY · COMPOSITEATOMIC SERVICES

Summary

Bookaroo explores the engineering behind a seemingly simple action: reserving and paying for an event ticket. The platform separates user management, events, booking, ticketing, billing, refunds and logging into independently managed services built with Spring Boot, FastAPI, Flask and other components.

A Kong API Gateway fronts the system, AWS Cognito supports identity and RabbitMQ connects asynchronous workflows. Services run in Docker, infrastructure is managed with Terraform and images live in Amazon ECR. Prometheus and Grafana provide service-level visibility.

Problem

An event booking is not a single atomic operation. Booking records, payments, ticket issuance, and refunds span multiple independently managed services and databases, making it difficult to maintain consistency across the entire workflow.

A payment may succeed while a subsequent ticketing operation fails, leaving the system in a partially completed state. The challenge is to coordinate these distributed operations, recover from failures, and maintain consistent booking and payment records without sacrificing service independence.

Concurrency introduces another challenge. When multiple customers attempt to purchase the last available ticket simultaneously, they may observe the same remaining inventory and create conflicting bookings. The system must prevent overselling while handling concurrent requests without compromising booking reliability.

Architecture

↳ Hover or focus any component to see what it connects to.

Bookaroo is a layered microservice system. Two Next.js interfaces, one for customers booking tickets and one for organisers managing events, call a Kong API gateway that checks JWT tokens against Amazon Cognito. Kong routes requests to three composite services: Book Event, Process Refund and Create Event. Book Event calls the Events, Ticket Management, Billing and Notification services. Process Refund calls Events, Ticket Management, Billing, User Management and Notification. Create Event calls Events, Billing, User Management and Notification. Each atomic service owns its storage: PostgreSQL for Events, Ticket and User, MySQL for Notification, and AWS S3 for event media. Billing calls Stripe and Notification sends email through Amazon SES. Logging is asynchronous: the three composite services and Ticket Management publish log messages to a durable RabbitMQ queue, the Logging service consumes that queue and stores each log in its own PostgreSQL database. Grafana reads metrics from Prometheus.

Booking UIcustomers · Next.jsManagement UIorganisers · Next.jsKong GatewayJWT AuthAmazon CognitoCreate EventProcess RefundBook EventRabbitMQdurable logs_queueUser ManagementBillingEventsNotificationOutSystemsTicketManagementLoggingconsumes logs_queuePostgreSQLUserAWS S3Events mediaPostgreSQLEventsMySQLNotificationPostgreSQLTicketPostgreSQLLoggingStripeAmazon SESGrafanaPrometheus
Fig. 01 — Bookaroo, system architecture

Two Next.js interfaces serve customers booking events and organisers managing them. Requests pass through Kong API Gateway, which validates JWT authentication using Amazon Cognito before routing requests to composite services responsible for booking, refunds, and event creation.

The composite services orchestrate domain-specific microservices for event management, ticketing, billing, user management, and notifications. Each service owns its data, reducing coupling and enabling independent development and deployment. Billing integrates with Stripe for payments, while notifications are delivered through Amazon SES.

Operational logging is handled asynchronously through RabbitMQ. Composite services and Ticket Management publish logging events to a message queue, which the Logging Service consumes and persists independently. This decouples logging from the main booking workflow, preventing logging operations from directly delaying user-facing requests.

Services are containerised using Docker, with infrastructure provisioned through Terraform and images stored in Amazon ECR. Prometheus and Grafana provide visibility into service health, API latency, throughput, and resource utilisation.

My Contributions

  • Contributed to the eight-service architecture, defining clear responsibilities for bookings, tickets, billing, refunds and adjacent capabilities.
  • Implemented Saga-based consistency handling for cross-service booking workflows, coordinating state changes and recovery from partial failures.
  • Developed RabbitMQ-driven asynchronous communication between services and integrated access control through Kong, JWT and AWS Cognito.
  • Containerised services and supported repeatable infrastructure with Docker, Terraform and Amazon ECR.
  • Integrated Prometheus and Grafana so service behaviour and operational health are visible.

Engineering Decisions

Database per service. Isolated databases reduce coupling and give each service ownership. The cost is that a booking spans several local commits that must be coordinated.

Asynchronous messaging for coordination. RabbitMQ decouples services and lets workflows span boundaries without one long synchronous request chain.

A Saga instead of one global transaction. The workflow is a sequence of locally committed steps. If a later step fails, compensating operations undo earlier effects. It gives practical eventual consistency, though recovery has to be designed and tested carefully.

Atomic inventory updates. Inventory availability checks and decrements are performed as a single atomic database operation. PostgreSQL's row-level locking serialises conflicting updates, ensuring only one concurrent request can reserve the final available ticket and preventing overselling without relying on application-level checks alone.

Results & Validation

  • Built a working eight-microservice platform spanning event discovery, bookings, ticketing, billing, refunds and supporting services.
  • Demonstrated Saga-based coordination for booking consistency and handling of partial cross-service failures.
  • Set up containerised development and infrastructure-as-code workflows for repeatable environments.
  • Configured dashboards for service availability, API latency, request rate, error rate, CPU and memory.

Stack

  • Next.js
  • Spring Boot
  • FastAPI
  • Flask
  • PostgreSQL
  • MySQL
  • RabbitMQ
  • Kong API Gateway
  • JWT
  • AWS Cognito
  • OutSystems
  • Stripe
  • Docker
  • Terraform
  • Amazon ECR
  • Flyway
  • Prometheus
  • Grafana