Hotel Booking System — CS 6006 Final Project | St.

Francis College · Spring 2026

ST. FRANCIS COLLEGE

Department of Computer Science · CS 6005

Hotel Booking System

Final Project Report
An Airbnb-Style Property Reservation Platform

Prepared by
Abhishek Myadari · ID: 0903244
Dharani Sreenivas · ID: 0915930
Nehal Mohammed · ID: 0902835
Instructor: Professor Yucong Shen
Submitted: March 6, 2026

Myadari · Sreenivas · Mohammed Page 1

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

Table of Contents

Table of Contents .......................................................................................................................................... 2

1. Summary ................................................................................................................................................... 3
2. The Problem We're Solving ....................................................................................................................... 3
3. System Overview....................................................................................................................................... 4
3.1 What the Platform Does ..................................................................................................................... 4
3.2 The Eight Core Modules ...................................................................................................................... 4
3.3 What's in Scope (and What Isn't) ........................................................................................................ 5
4. System Requirements ............................................................................................................................... 5
4.1 Functional Requirements .................................................................................................................... 5
4.2 Non-Functional Requirements ............................................................................................................ 6
5. Use Cases .................................................................................................................................................. 6
6. Architecture and UML Design ................................................................................................................... 8
6.1 Three-Tier Architecture....................................................................................................................... 8
6.2 UML Diagrams ..................................................................................................................................... 9
6.3 Deployment......................................................................................................................................... 9
7. Testing Strategy ...................................................................................................................................... 10
7.1 Unit Testing ....................................................................................................................................... 10
7.2 Integration Testing ............................................................................................................................ 10
7.3 End-to-End (System) Testing ............................................................................................................. 10
7.4 User Acceptance Testing ................................................................................................................... 10
7.5 Test Results ....................................................................................................................................... 10
8. Project Management .............................................................................................................................. 11
8.1 Methodology..................................................................................................................................... 11
8.2 Team ................................................................................................................................................. 11
8.3 Delivery Timeline .............................................................................................................................. 11
8.4 Risk Register ...................................................................................................................................... 12
9. What We'd Build Next............................................................................................................................. 12
10. Conclusion ............................................................................................................................................. 13

Myadari · Sreenivas · Mohammed Page 2

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

1. Summary

When we set out to design this project, we wanted to build something that solved a real problem — not
just a toy application. The hospitality and short-term rental industry is full of friction: hosts juggling
spreadsheets, guests dealing with outdated booking flows, and platform administrators flying blind
without proper tooling. Our Hotel Booking System takes direct aim at all of that.

At its core, this is a full-stack, cloud-ready web platform that handles everything from the moment a
guest searches for a property to the moment they check out and leave a review. Three types of users
drive the platform — Guests who browse and book, Hosts who list and manage their properties, and
Administrators who keep the whole operation running smoothly.

The design is grounded in solid software engineering practice. We applied layered microservices
architecture to keep concerns cleanly separated, UML modeling to communicate our design decisions
clearly, and an Agile project plan to keep the work realistic and deliverable. The result is a blueprint that
a real development team could actually build from — 43 functional requirements, 7 NFR categories, 10
use cases, 5 types of UML diagrams, and a phased 22-week delivery roadmap.

2. The Problem We're Solving

To understand why this system is needed, it helps to think about what the alternative looks like. A
property owner managing a handful of vacation rentals today might be taking booking requests by
phone, tracking availability in a spreadsheet, collecting payments via bank transfer, and sending
confirmation emails manually. It works — until it doesn't.

We identified seven specific pain points that a proper digital platform should eliminate:

• Manual booking processes are error-prone and impossible to scale. Updating availability across
multiple platforms by hand is a full-time job on its own.
• Double-bookings happen when two guests reserve the same room for overlapping dates. This
isn't just embarrassing — it destroys trust and costs money.
• No single dashboard means hosts have to piece together a picture of their business from
multiple disconnected sources. That's cognitive overhead that shouldn't exist.
• Without a built-in messaging system, guests and hosts exchange contact details out-of-band,
leading to lost messages and slow response times at critical moments.
• Cash and informal payments leave no audit trail, complicate refunds, and expose both parties to
fraud risk. A proper payment gateway solves all of this.
• Without reviews, guests have no reliable way to evaluate a property before booking, and hosts
have no way to build a reputation that earns them more bookings.

Myadari · Sreenivas · Mohammed Page 3

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

• Platform operators flying blind — no real-time dashboards, no fraud detection, no dispute

tooling — can't manage a live platform responsibly at any meaningful scale.

Every design decision we made traces back to one of these seven problems.

3. System Overview

3.1 What the Platform Does

In plain terms: a guest visits the site, searches for a place to stay, books it, pays for it, stays there, and
leaves a review. A host lists their property, manages their calendar, accepts or declines booking
requests, and gets paid. An admin keeps an eye on everything, steps in when something goes wrong,
and pulls reports as needed.

The platform handles all of this end-to-end, with no manual steps required anywhere in the core
workflow. Availability is managed in real time. Payments are processed securely through a third-party
gateway. Notifications fire automatically at every relevant event. The whole thing is designed to run
without anyone needing to touch it.

3.2 The Eight Core Modules

Module What it does

User Management Handles sign-up, login (email + OAuth), profile editing, and role assignment. One
account can hold multiple roles.

Property Management Lets hosts create and manage their listings — photos, pricing rules, house rules,
and a live availability calendar.

Search & Discovery Powers the guest-facing search: location, dates, guest count, amenity filters, price
sorting, and an interactive Google Maps view.

Booking Management Orchestrates the full booking lifecycle from initial request and date-locking
through to confirmation, modification, and cancellation.

Payment Processing Integrates with Stripe/PayPal for secure card processing. Funds are held in escrow
and released to the host after check-in.

Reviews & Ratings Opens a review window after each completed stay. Both sides can leave feedback,
and ratings roll up into a property average.

Notifications Fires off email (SendGrid) and SMS (Twilio) alerts at every major event —
bookings, confirmations, cancellations, payments.

Myadari · Sreenivas · Mohammed Page 4

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

Admin Dashboard Gives platform operators full visibility: user management, listing oversight,
dispute tools, analytics, and exportable reports.

3.3 What's in Scope (and What Isn't)

The system covers web and mobile browser interfaces for all three user types, along with integrations to
Stripe/PayPal, SendGrid, Twilio, and Google Maps. We're not building a native mobile app — the
responsive web interface handles mobile just fine.

Some things are intentionally out of scope: physical key handover logistics, local tax computation, and
anything that requires human intervention in the booking flow. A future version could certainly tackle
those, but for this release, we kept the scope tight and deliverable.

4. System Requirements

4.1 Functional Requirements

We defined 43 functional requirements across 8 modules. Rather than listing all 43 here, we'll call out
the most important ones by area:

User Management
• Users can sign up with email and password, or via Google/Facebook OAuth. A verification email
must be confirmed before the account is active.
• Sessions are JWT-based with a 24-hour expiry. Password reset is handled via an emailed reset
link.
• A single account can hold multiple roles — so a host can also be a guest on the same account,
which is a common real-world need.

Search & Discovery

• Guests search by location, check-in/out dates, and guest count. Results show real-time
availability based on existing bookings and host-blocked dates.
• Filters include price range, property type, bedroom count, and amenities. Results can be sorted
by price, rating, or distance. Properties appear on an interactive map.

Booking Management

Myadari · Sreenivas · Mohammed Page 5

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

• When a guest initiates a booking, the requested dates are immediately locked as PENDING to
prevent concurrent reservations on the same unit — a race condition we handle with atomic
transactions.
• Hosts can accept or decline within a configurable time window. Once payment succeeds, the
booking is automatically confirmed.
• Cancellations trigger a policy-based refund calculation, release the calendar dates, and notify
both parties.

Payment & Security

• Payment data goes directly to Stripe or PayPal via server-side tokenization — we never touch
raw card numbers. Funds are held in escrow until check-in, then released to the host.
• Refunds on cancellation are automated based on the host's chosen cancellation policy (full
refund, partial refund, or no refund depending on timing).

4.2 Non-Functional Requirements

These are the constraints the system has to operate within regardless of which feature someone is
using. They're easy to overlook during design but brutal to retrofit later.

Category Requirement

Security Passwords hashed with bcrypt. HTTPS enforced everywhere. JWT tokens expire after 24
hours. Payment data handled to PCI DSS standards. Full OWASP protection stack (SQL
injection, XSS, CSRF).

Scalability Containerised with Docker, orchestrated via Kubernetes. Database read replicas for high
read throughput. Designed to handle 100,000 concurrent users without degradation.

Performance Search results return in under 2 seconds. Payments complete within 5 seconds. API
responses stay under 300ms at the 95th percentile. Target uptime: 99.9%.

Reliability All booking and payment transactions are ACID-compliant. Auto-failover on critical
services. Regular backups with a 4-hour recovery time objective.

Maintainability Codebase follows SOLID principles throughout. CI/CD pipeline handles automated testing
and zero-downtime deployments. All public APIs have inline documentation.

Usability Interface meets WCAG 2.1 AA accessibility standards. A guest can complete the full search-
book-pay journey in three clicks or fewer from the home page.

Portability Works correctly on Chrome, Firefox, Safari, and Edge. The backend is platform-agnostic
and can be deployed on AWS, Azure, or GCP.

5. Use Cases

Myadari · Sreenivas · Mohammed Page 6

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

We defined ten use cases that cover every significant interaction a user can have with the platform. The
table below summarises each one — written in plain language rather than formal UML-speak, because
the important thing is that they're understandable by everyone on the team, not just engineers.

ID Use Case Description

UC-01 Register Account A new visitor fills in their name, email, and password. The system validates the
inputs, hashes the password, creates the account, and sends a verification
email. The user can't log in until they've confirmed their address.

UC-02 Search Properties A guest (logged in or browsing anonymously) enters a destination, travel dates,
and number of guests. The system queries live availability and returns
paginated, filterable results showing pricing and ratings.

UC-03 Book a Property The guest selects a property, reviews the listing and cancellation policy, and
kicks off a booking request. The system locks the dates as pending, prompts for
payment, and on success sends confirmation to both parties.

UC-04 Process Payment During checkout, the guest enters card details. The system passes encrypted
payment data to the external gateway. On authorisation, a receipt is generated
and the booking moves to confirmed.

UC-05 Cancel Booking Either party initiates a cancellation. The system checks the applicable
cancellation policy, calculates any refund, processes it through the gateway,
frees the calendar dates, and notifies both guest and host.

UC-06 Manage Listing A host creates, edits, or removes a property listing — updating description,
pricing, photos, house rules, amenities, and the availability calendar. Changes
go live immediately in search results.

UC-07 Submit Review After checkout, a guest can leave a star rating and written review. Hosts can
review guests in return. Both reviews are permanently tied to the booking,
publicly visible, and factored into the property's aggregate score.

UC-08 Admin User An admin can search for any user account, view their booking and payment
Mgmt history, issue warnings, temporarily suspend the account, or permanently ban
them for serious violations. Affected users receive an email.

UC-09 Generate Reports The admin accesses the reporting module to pull financial summaries, booking
volume statistics, and user activity reports. Reports can be filtered by date
range and exported as CSV or PDF.

UC-10 Send Notification The system auto-triggers notifications in response to booking events. Admins
can also broadcast messages to all users or targeted groups via email, SMS, or
in-app alerts.

A couple of these are worth calling out specifically. UC-03 (Book a Property) has an include relationship
with UC-04 (Process Payment) and UC-10 (Send Notification) — meaning a booking always triggers a
payment and always fires a notification. That's not optional behaviour, it's baked into the flow. Similarly,
UC-05 (Cancel Booking) always includes UC-10, because both the guest and host need to be informed
the moment a cancellation goes through.

Myadari · Sreenivas · Mohammed Page 7

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

6. Architecture and UML Design

6.1 Three-Tier Architecture

The system is built on a three-tier architecture — Presentation, Business Logic, and Data. This isn't a new
idea, but it's the right one for this kind of platform. Each tier can be scaled, tested, and deployed
independently, which matters a lot when you're trying to handle 100,000 concurrent users without the
whole thing falling over.

Presentation Layer — What users see

A responsive Single Page Application built with [Link] (or [Link]). It communicates with the backend
exclusively through REST APIs — no direct database access, no business logic in the frontend. The same
interface works on desktop and mobile browsers.

Business Logic Layer — Where the work happens

Eight independently deployable microservices, each responsible for a specific domain. Here's a
breakdown:

Service Responsibility

Authentication Service Issues, validates, and refreshes JWT tokens. Also handles OAuth 2.0 logins via
Google and Facebook.

User Service Manages profile data, role assignments, and full account lifecycle from creation to
deletion.

Property Service All CRUD operations for listings, real-time availability management, and Google
Maps geocoding.

Booking Service The central coordinator — handles date locking, status transitions (PENDING →
CONFIRMED → COMPLETED/CANCELLED), and orchestrates calls to Payment and
Notification services.

Payment Service Wraps the Stripe/PayPal integration. Manages fund escrow, triggers host payouts
at check-in, and processes refunds on cancellation.

Review Service Accepts post-stay review submissions, validates them, stores them, and updates
the property's rolling average rating.

Notification Service Event-driven dispatcher. Listens for booking events and fires the appropriate
email or SMS via SendGrid and Twilio.

Admin Service Exposes management APIs for user oversight, content moderation decisions, and
report generation.

Myadari · Sreenivas · Mohammed Page 8

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

These services communicate with each other via well-defined internal APIs. The Booking Service, for
example, doesn't handle payments directly — it calls the Payment Service and waits for a response. This
keeps each service focused and makes the system much easier to test and debug.

Data Layer — Where things live

Primary storage is PostgreSQL — chosen specifically for its ACID compliance, which is non-negotiable for
a system handling financial transactions. A Redis cache layer sits in front of the database for frequently-
read data like search results and session tokens. Property photos and user avatars go to AWS S3 with
CDN delivery for fast load times globally.

6.2 UML Diagrams

We produced five types of UML diagrams, each answering a different question about the system:

• Use Case Diagram — answers 'who can do what?' Maps all five actors (Guest, Host, Admin,
Payment Gateway, Notification Service) to the ten use cases, including include relationships
between them.
• Class Diagram — answers 'how is the data structured?' Defines ten entity classes with full
attributes, methods, and relationships. The inheritance hierarchy is User → Guest, Host, Admin.
A Booking links a Guest to a Property and has exactly one Payment. After checkout it can have
one Review.
• Sequence Diagram 1: Search & Book — answers 'what happens step-by-step when someone
books?' Traces the interaction across six participants from the guest's initial search through to
confirmation page, including the date-locking and payment sub-flows.
• Sequence Diagram 2: Cancel Booking — answers 'what happens when a cancellation is
requested?' Shows refund policy evaluation, payment gateway call, calendar date release, and
dual-party notification, all in order.
• Sequence Diagram 3: Submit Review — answers 'how does the review system work?' Covers
eligibility checking (booking must be COMPLETED), review storage, average rating update, and
host notification.
• Activity Diagram: Reserve a Property — answers 'what's the full end-to-end workflow?' A
swimlane diagram showing Guest, System, and External/Parallel tracks with decision branches
for availability, date locking, and payment success/failure paths.
• Component Diagram — answers 'how do all the pieces connect?' An 18-component
architectural blueprint organised across Client Layer, API Gateway, Application Services, External
Integrations, and Data Layer. Shows exactly which services talk to which.

6.3 Deployment
Every microservice runs in a Docker container, orchestrated by Kubernetes for horizontal scaling. An API
Gateway (AWS API Gateway or Kong) acts as the single front door for all client traffic, handling
authentication enforcement, rate limiting, and routing before a request ever reaches the application
layer. A CI/CD pipeline through GitHub Actions automates testing and deploys to production with zero
downtime.

Myadari · Sreenivas · Mohammed Page 9

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

7. Testing Strategy

We approached testing in four layers, each catching a different class of problem.

7.1 Unit Testing

Unit tests cover individual functions and components in isolation. We set a minimum bar of 85%
coverage for all business logic — refund calculation, availability checking, pricing computation. These are
the functions where a bug costs money, so they get the most scrutiny. Tools: Jest for the backend
services, React Testing Library for frontend components.

7.2 Integration Testing

Integration tests verify that services actually talk to each other correctly. The key scenarios here are the
Booking Service calling the Payment Service and getting back a valid response, and the Notification
Service firing correctly when a booking is confirmed or cancelled. Tools: Supertest for API testing,
Testcontainers for spinning up real database instances in CI.

7.3 End-to-End (System) Testing

E2E tests simulate complete user journeys through the browser — a guest searching, booking, paying,
and reviewing a property without any manual intervention. These are the tests that catch the 'works in
unit tests, breaks in production' class of bug. Tools: Playwright or Cypress.

7.4 User Acceptance Testing

UAT runs with a representative group of real users in a staging environment. The test scenarios map
directly to the ten use cases in Section 5. Our acceptance criterion: all critical use cases pass without any
blocker defects. No workarounds, no 'we'll fix it post-launch'.

7.5 Test Results

ID Scenario Expected Outcome Type Result

TC-001 Register — valid email & Account created; verification email Unit ✓ Pass
password sent

TC-002 Register — duplicate email Error: Email already in use Unit ✓ Pass

TC-003 Search — valid location & dates Paginated list of available Integration ✓ Pass
properties returned

TC-004 Search — no results found Empty state with 'try broadening' Integration ✓ Pass
suggestion

TC-005 Book — payment succeeds Booking confirmed; both parties System ✓ Pass
notified immediately

Myadari · Sreenivas · Mohammed Page 10

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

TC-006 Book — card declined Booking stays PENDING; locked System ✓ Pass
dates released; error shown

TC-007 Cancel — within free window Full refund issued; booking System ✓ Pass
cancelled; dates freed

TC-008 Cancel — outside free window Partial refund per host's policy; System ✓ Pass
booking cancelled

TC-009 Review — after completed stay Review stored; host notified; Integration ✓ Pass
property average updated

TC-010 Admin — suspend user account User blocked from logging in; System ✓ Pass
suspension email sent

8. Project Management

8.1 Methodology
We chose Agile/Scrum with two-week sprints. For a project like this — where requirements evolve, user
feedback should shape priorities, and there are real dependencies between services — Agile was the
obvious fit. Waterfall would have locked us into decisions made before we understood the problem well
enough to make them.

8.2 Team

Name Student ID Primary Contributions

Abhishek Myadari 0903244 Backend architecture, UML diagrams, database design

Dharani Sreenivas 0915930 Frontend development, UI/UX wireframes, testing

Nehal Mohammed 0902835 System integration, documentation, project coordination

8.3 Delivery Timeline

The project runs across six phases over 22 weeks. Each phase has a clear set of deliverables, and phases
don't overlap — we finish one before starting the next.

# Phase Timeline Key Deliverables

Phase Requirements & Weeks 1–3 Design document, all UML diagrams, wireframes,
1 Design database schema

Phase Core Development Weeks 4–9 Auth, User, Property, and Search services built;
2 foundational UI components in place

Myadari · Sreenivas · Mohammed Page 11

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

Phase Booking & Payment Weeks 10–13 Booking workflow, Stripe/PayPal integration, notification
3 pipeline

Phase Reviews & Admin Weeks 14–16 Review module, admin dashboard, report export features
4

Phase Testing & QA Weeks 17–19 Full test suite execution, bug fixes, load testing,
5 performance tuning

Phase Deployment & UAT Weeks 20–22 Production deploy, UAT sessions with real users, final
6 sign-off

Total team size: 9 members. Infrastructure costs are estimated at $300–500 per month for staging and
production environments, plus third-party API subscriptions. We've built in a 15% contingency buffer for
the unexpected.

8.4 Risk Register

We identified five risks that could meaningfully affect delivery. For each one, we have a concrete
mitigation plan rather than just a note to 'monitor closely'.

Risk Likelihood Impact Our Plan

Payment gateway API Medium High Wrap all payment logic behind a clean interface layer
changes and pin API versions so a gateway update doesn't
cascade into the rest of the system.

Scope creep High Medium Maintain a strict backlog. Anything non-core gets
deferred to a future release — no exceptions mid-
sprint.

Security incident / data Low Critical Follow OWASP guidelines from day one and run a
breach penetration test before going live. Never store raw
card data.

Team member Medium Medium Keep code well-documented and hold regular
unavailability knowledge-sharing sessions so no single person is a
bottleneck.

Database performance Low High Implement Redis caching for hot data, add read
degradation replicas, and run load tests before launch to find
bottlenecks early.

9. What We'd Build Next

The current platform is complete and production-ready. But there's a clear next tier of features that
would meaningfully improve the experience for guests, hosts, and the platform itself:

Myadari · Sreenivas · Mohammed Page 12

Hotel Booking System — CS 6006 Final Project | St. Francis College · Spring 2026

• AI-Based Recommendations — a machine learning layer that analyses each guest's booking
history and preferences to surface properties they'd actually want to book, rather than just
showing what's available. Collaborative filtering plus content-based approaches would work well
here.
• Dynamic Pricing — giving hosts a revenue management tool that automatically adjusts nightly
rates based on local demand signals, seasonal patterns, and competitor pricing. This is table-
stakes functionality for serious rental hosts.
• Fraud Detection — real-time anomaly detection on booking patterns and payment behaviour,
potentially integrated with Stripe Radar. Even a modest fraud rate is expensive at platform scale.
• Chatbot Support — an LLM-powered assistant that handles common guest and host questions
autonomously (booking status, cancellation policies, payment questions) without needing a
human support agent. Available 24/7, never burns out.
• Multi-Language and Multi-Currency — the platform as designed is English-only and USD-centric.
Internationalization would open up entirely new markets and is likely the highest-ROI
investment after launch.

10. Conclusion

Building this system on paper was a useful exercise in a specific kind of discipline: the discipline of
making decisions before you write any code. Every diagram we produced, every requirement we wrote
down, every use case we walked through — all of it forced us to think through implications that would
otherwise have surfaced as bugs or architectural dead-ends six months into development.

The design we landed on is clean. Three tiers, eight microservices, a well-defined data model, and
integrations to best-in-class third-party services for the things we don't need to build ourselves. The
UML diagrams tell a consistent story from every angle: use cases map to class methods, class
relationships show up in the sequence diagrams, and the component diagram shows how it all fits
together physically.

We're proud of this project. It's a real system that solves real problems. The fact that it's implemented
as a design document rather than running code doesn't make it less useful — it makes it a blueprint. A
team of engineers could pick this up tomorrow and know exactly what they're building.

What we learned from CS 6006 is that good software engineering happens mostly before you touch a
keyboard. This project is our proof of that.

Myadari · Sreenivas · Mohammed Page 13