Why this matters
- Date-range overlap is a classic algorithm + OOP combo question.
- Room inventory contention appears in hotel, flight, and meeting scheduler problems.
- Cancellation and modification rules test whether your model is flexible.
- Strong answers separate search, hold, confirm, and cancel as distinct operations.
BookingService
Resourceroom, seat, table
TimeSlotstart, end, capacity
Reservationstatus, userId
CampusOS context
CampusOS is the fictional smart-campus platform used across this track. Treat this module as a real product slice:
Context
- Belongs to CampusOS — same naming and design vocabulary as parking, library, and booking modules
- Scope is one JVM — persistence is in-memory or behind a repository interface
- Goal is a class diagram + core Java that an interviewer can follow in 35–45 minutes
- Extension paragraph at the end links to System Design when scale exceeds one process
Requirements snapshot
Functional requirements
- Search hotels by city, check-in, check-out, and guest count
- Room types (single, double, suite) with different capacity and price
- Reserve room for date range; prevent double booking same room
- Modify dates or cancel according to policy
- Guest profile stores booking history
- Admin manages room inventory and pricing
Non-functional requirements
- Efficient availability query for date ranges
- Consistent read of inventory during concurrent reservations
- Cancellation policy enforced in domain layer
Overview
This CampusOS module designs Hotel Booking as a production-ready in-process service. Read requirements point-by-point before drawing classes.
Requirements
Points to cover
- Search hotels by city, check-in, check-out, and guest count
- Room types (single, double, suite) with different capacity and price
- Reserve room for date range; prevent double booking same room
- Modify dates or cancel according to policy
- Guest profile stores booking history
Room types
Points to cover
RoomTypeenum or class: SINGLE, DOUBLE, SUITE with capacity and base rate- Physical
Roomhas number, floor, type, and maintenance status - Pricing may vary by season — Strategy or rate table
- Search filters by type, price range, amenities
Date overlap
Points to cover
- Reservation is
[checkIn, checkOut)— checkout day is exclusive - Two bookings conflict if ranges overlap on same
Room - Query: for each room, merge or scan sorted reservations
- Hold tentative booking with TTL before payment confirms
- Index by room ID + date for fast availability
Cancellation
Points to cover
- Cancel frees inventory for remaining nights
- Policy: free cancel before N days; fee otherwise
- Partial stay modification = cancel + rebook atomically
- Emit domain event for notification service
// CampusOS — HotelBooking facade (keep thin)
public final class HotelBookingService {
private final HotelBookingRepository repository;
public HotelBookingService(HotelBookingRepository repository) {
this.repository = repository;
}
/** Orchestrate: validate → domain rules → persist → return result */
public Result handle(Request request) {
request.validate();
var domain = DomainModel.from(request);
domain.applyRules();
return repository.save(domain);
}
}
Quick recall
Everything you need if you only revisit this box.
- Requirements — review this slice before mock interviews.
- Room types — review this slice before mock interviews.
- Date overlap — review this slice before mock interviews.
- Cancellation — review this slice before mock interviews.
CampusOS extension
When this outgrows one JVM
- Shard inventory or state by campus ID or geographic region
- Push notifications, payments, and search to dedicated services (System Design track)
- Use message queues for async side effects (email, analytics)
- The class diagram you drew here becomes one box on the HLD architecture diagram
Test yourself
Answer these before moving on — recall is what makes it stick.