System requirements

Functional:

User search functionality

• user can search for a room based on:
  • location (static, not a map service)
  • check-in date
  • check out dates
  • number of guests
• user can view search results that:
  • show available rooms
  • price

Room booking process

• user enters his data
• user can review booking details before confirmation

Payment Process

• user pays to reserve the room
  • we will use a 3rd party payment gateway like checkout.com

Hotel staff Management process

• staff can cancel or reject a reservation
• update room information

Non-Functional:

1. Concurrency:
   • Ensure no two users can book the same room at the same time. This can be achieved through:
     • Locking Mechanism: Implement optimistic or pessimistic locking to manage access to room availability.
     • Idempotent APIs: Design the booking API to be idempotent using:
       • User-specific tokens or session IDs to prevent multiple bookings from the same user session.
       • Rate limiting based on user IP or token to prevent rapid repeated requests.
2. Scalability:
   • The system must support a high number of queries per second (QPS). If the QPS exceeds 1,000:
     • Database Sharding: Apply sharding to the database using a sharding key based on hotel_id. This will distribute the load and ensure faster queries.
     • Consider using a microservices architecture to allow each service to scale independently.
3. Performance:
   • Hotel service cache: The system should respond to user queries within 2 seconds for search results. So we can use a cache system for hotel info, like images, description, etc...
   • Adyen Payment processing: we will use Adyen as a 3rd party payment system, payments should be completed within a reasonable time (ideally under 3 seconds) to ensure user satisfaction.
4. Security:
   • Implement both frontend & backend input validations
   • Use HTTPS for all communications between the client and server.
5. Maintainability:
   • The codebase should follow best practices and coding standards to facilitate future updates.
   • Use logging and monitoring to enable easy troubleshooting and performance tracking.

Capacity estimation

1. Expected Users: Estimate how many users will access the system at peak times, let’s assume:
   • 10,000 active users per day.
   • On average, 1,000 concurrent users during peak hours.
2. Requests per User: how many requests each user might make:
   • Searching for hotels: 3 requests (arrival, first search, additional filters)
   • Booking a room: 1 request
   • Payment requests: 1 request
   • Management actions (e.g., checking booking status): 2 requests
   • Total: Approx. 7 requests per user
3. Peak Load Estimation:
   • Assume peak traffic lasts for 2 hours and is concentrated in that period.
   • 1,000 concurrent users making 7 requests over 2 hours.

Calculation Steps

1. Total Requests
   • Total Active Users: 10,000
   • Peak Users during peak hours: 1,000
   • Requests per User: 7
2. Total Requests Per Second (RPS)= 1,000 users x 7 requests per user = 7000 requests
3. Since we are considering a two-hour peak period, we convert that into seconds. There are 7,200 seconds in two hours (2 hours × 60 minutes × 60 seconds).
4. divide 7000 requests by 7200 seconds is equal to 0.97 RPS
5. Adjust for Growth and Scaling:
   • Let's estimate for growth, say you want to handle 30% more concurrent users for scaling purposes.
   • Total concurrent users for scaling: 1,000 multiplied by 1.3 = 1,300
6. 1,300 users multiplied by 7 requests divided by 7200 seconds is equal to 1.24 RPS

Summary

• Base RPS: Approximately 1 request per second for 1,000 concurrent users.
• Adjusted RPS for Growth: Around 1.24 RPS for 1,300 concurrent users

API design

1. Search Service:
   • Endpoint: GET /v1/hotels/rooms
     • Query Parameters:
       • startDate: The check-in date
       • endDate: The check-out date
       • Additional parameters such as location, numberOfGuests
     • Response: A list of available rooms with details (e.g., hotel name, room type, prices, amenities).
2. Booking Service:
   • Endpoint: POST /v1/bookings
     • Request Body:
       • roomId: ID of the room to be booked
       • guestDetails: Information about the guest (name, contact)
       • paymentDetails: Payment information (secured)
     • Response: Confirmation of booking including booking ID, room details, and payment status.
     • Idempotency: we can use the booking ID in the payment request to insure idempotency
3. Payment Service:
   • Endpoint: POST /v1/payments
     • Request Body:
       • bookingId: ID of the booking for which the payment is being made
       • paymentMethod: Details of the payment method being used (e.g., credit card info)
     • Response: Payment confirmation, including transaction details and status.
4. Management Service:
   • Endpoints:
     • GET /v1/bookings/{bookingId}: Retrieve booking details for a specific booking ID.
     • PUT /v1/bookings/{bookingId}: Allow users to update their booking details (e.g., date changes, guest details).
     • DELETE /v1/bookings/{bookingId}: Allow users to cancel their booking.

Database design

1. User: Contains all necessary user information such as ID, name, email, password, and phone number.
2. Hotel: Holds hotel details including name, location, and description.
3. Room: Details about the rooms, including which hotel they belong to, their type, pricing, and availability.
4. Booking: Contains booking details linking a user to a room for specific dates, including status, BookingID & RoomID.
5. Payment: Tracks payment details linked to bookings, including payment method and status. The fields may include, TransactionID, BookingID, PaymentStatus

High-level design

HLD is included in the attached "High level diagram".

Key Elements

• Public Services are encapsulated in the Public_Services subgraph.
• Private Services are encapsulated in the Private_Services subgraph.
• Each service interaction is clearly defined, showing which databases they connect to.

The follwoing are the main components of this architecture

1. Public Requests: Users send requests to the API Gateway, which directs the traffic to the public services.
2. Public Services: The Load Balancer distributes traffic among the Search, Booking, and Payment Services. These services are all publicly accessible.
3. Private Services: The Hotel Management Service is placed on the other side, indicating it operates independently without direct public access.
4. User: The end-user interacts with the system through requests.
5. API Gateway: Serves as the single entry point for all client requests, handling routing and authentication.
6. Load Balancer: Distributes incoming requests evenly across the API servers to ensure scalability and high availability.
7. Services:
   • Search Service: Handles room search queries and interacts with its dedicated database.
   • Booking Service: Manages booking requests and transactions, using a shared database with the Payment Service.
   • Payment Service: Processes payment transactions and interacts with the shared Booking & Payment database.
   • Hotel Management Service: Manages hotel information and interacts with its own database and the cache for fast access.
8. Databases:
   • Search Database: Dedicated for the Search Service, optimizing queries related to room searches.
   • Booking & Payment Database: Shared by both the Booking and Payment Services to ensure consistency.
   • Hotel Management: accesses the Search Database.
9. Cache Storage: Utilized by the Hotel Management Service and Search service to quickly access frequently-needed hotel images and metadata, improving performance.

Additional Considerations

• Scalability: Each service can be scaled independently based on demand.
• Data Sharding: Implement sharding for the Booking & Payment database to handle peak load effectively, distributing data across multiple database instances.
• Monitoring & Logging: Consider adding monitoring for performance tracking and error logging for incident management.

Request flows

Sequence diagram is included in the attached "Sequence diagram".

End-to-End Request Flow

1. User Initiates Room Search:
   • Action: User enters search criteria (location, check-in/out dates, number of guests) on the client interface.
   • Request: GET /v1/hotels/rooms?location={location}&startDate={checkIn}&endDate={checkOut}
   • Components Involved:
     • User Interface → API Gateway → Load Balancer → Search Service
   • Response: Search Service queries the Search Database and returns available rooms to the API Gateway.
2. User Views Search Results:
   • Action: User views a list of available rooms displayed after search.
   • Response: Search results are presented with room details and pricing.
3. User Selects a Room to Book:
   • Action: User selects a preferred room and clicks on the "Book Now" button.
   • Request: POST /v1/bookings with body containing room ID, user details, and dates.
   • Components Involved:
     • User Interface → API Gateway → Load Balancer → Booking Service
   • Response: Booking Service processes the request.
4. User Provides Payment Information:
   • Action: User enters payment details (card information).
   • Request: POST /v1/payments with body containing booking ID and payment info.
   • Components Involved:
     • User Interface → API Gateway → Load Balancer → Payment Service
   • Response: Payment Service confirms payment and updates the Booking Service.
5. Booking Confirmation:
   • Response: After successful payment, the Booking Service returns a confirmation with booking details (Booking ID, room info, payment status).
   • The response is sent back through the API Gateway to the User Interface.
6. User Receives Booking Confirmation:
   • Action: User sees the booking confirmation on their interface.
   • Final Output: A summary of booking information along with a confirmation number is displayed.

Detailed component design

. Search Service

Responsibilities:

• Handle user search requests for available rooms based on various criteria (location, dates, number of guests).
• Retrieve and filter available rooms from the database.
• Return search results to the user with relevant details such as price, amenities, and availability.

Interactions:

• Receives requests from the API Gateway.
• Queries the Search Database for available rooms.
• Returns results back through the Load Balancer and API Gateway to the user.

API Endpoints:

• Search Rooms:
  • Endpoint: GET /v1/hotels/rooms
  • Query Parameters:
    • location: The location where the user wants to find hotels.
    • startDate: Check-in date.
    • endDate: Check-out date.
    • numberOfGuests: Number of guests.
  • Response: A list of available rooms with details (hotel name, room type, price, amenities).

Data Storage:

• Search Database:
  • Tables:
    • Hotels: Contains hotel details (ID, name, location, description).
    • Rooms: Contains room details (ID, hotel_id, room_type, price, amenities, available status).
  • Indexing: Important fields (like location and availability) should be indexed to enhance search performance.

2. Booking Service

Responsibilities:

• Manage room booking requests from users.
• Ensure room availability before confirming a booking.
• Create booking records and maintain booking status.
• Process and handle user payments by interacting with the Payment Service.

Interactions:

• Receives booking requests from the API Gateway via the Load Balancer.
• Validates room availability with the Search Database.
• Creates a booking record upon successful availability check and returns confirmation to the user.
• Communicates with the Payment Service to process payments.

API Endpoints:

• Create Booking:
  • Endpoint: POST /v1/bookings
  • Request Body:
    • roomId: The ID of the room being booked.
    • userId: The ID of the user making the booking.
    • checkIn: Check-in date.
    • checkOut: Check-out date.
  • Response: Booking confirmation including booking ID and status.

Data Storage:

• Booking & Payment Database:
  • Tables:
    • Bookings: Contains booking details (ID, room_id, user_id, check_in, check_out, status).
    • Payments: Contains payment transaction details (ID, booking_id, amount, payment_method, status).
  • Referential Integrity: Constraints should be applied to link booking records with their corresponding room and user records.

Trade offs/Tech choices

1. Use of API Gateway

Trade-offs:

• Complexity vs. Simplification:
  • Choice: Implementing an API gateway can introduce complexity (routing, authentication, etc.) but simplifies client interactions by providing a single entry point.
  • Rationale: Using an API gateway allows for centralized handling of concerns like rate limiting, authentication, and logging, which enhances security and maintainability.

2. Load Balancer

Trade-offs:

• Increased Availability vs. Cost:
  • Choice: I did chose a load balancer to distribute requests across multiple instances of API servers.
  • Rationale: This design improves application availability and responsiveness during peak traffic, ensuring users experience minimal latency. While it adds cost (in infrastructure), the performance benefit often outweighs this.

3. Microservices Architecture

Trade-offs:

• Scalability vs. Complexity:
  • Choice: I've designed the system using microservices for Search, Booking, Payment, and Hotel Management.
  • Rationale: Microservices permits to scale each component independently based on demand, enhancing the overall system's efficiency. However, operational complexity increases due to the need for service discovery and communication handling.

4. Relational Database with Sharding

Trade-offs:

• Data Integrity vs. Performance:
  • Choice: I chose a relational database (SQL) and planned sharding based on hotel_id to support peak hours.
  • Rationale: Relational databases provide strong consistency and integrity, crucial for transactions like bookings and payments. Sharding helps improve performance and scalability at high loads, but it also complicates queries and data management.

5. Shared Database for Booking and Payment Services

Trade-offs:

• Consistency vs. Bottlenecks:
  • Choice: The decision for the Booking Service and Payment Service to use the same database allowed for data consistency between bookings and payments.
  • Rationale: This choice simplifies the management of payment transactions related directly to bookings but can also lead to a bottleneck during high traffic, impacting performance.

6. Caching in Hotel Management Service

Trade-offs:

• Performance vs. Freshness:
  • Choice: I implemented caching for hotel images and metadata to enhance the performance of the Hotel Management Service.
  • Rationale: Caching improves response times for users requesting hotel information. However, this may result in stale data if caches are not invalidated appropriately, requiring careful cache management strategies.

7. Public vs. Private Access for Services

Trade-offs:

• Security vs. Accessibility:
  • Choice: The public accessibility of Search, Booking, and Payment Services, versus the private access of Hotel Management Service.
  • Rationale: Public access to core booking functions allows for seamless user interaction, while keeping the Hotel Management Service private improves security and protects sensitive operations. This separation balances user experience with security needs.

Summary of Reasons Behind Choices

1. Performance and Scalability: The choices of using microservices, a load balancer, and sharding reflect a focus on handling high traffic and ensuring application performance.
2. Consistency and Data Integrity: The choice of a relational database and shared database for services emphasizes the importance of maintaining consistent and accurate data.
3. User Experience: The design decisions related to caching and API gateways are geared towards enhancing the user experience by minimizing wait times and simplifying interactions.

Failure scenarios/bottlenecks

1. API Gateway Failures

Scenario:

• The API Gateway could become a single point of failure. If it goes down, all incoming traffic to your services would be halted.

Impact:

• Users would be unable to access any functionality of the application (search, booking, payment).
• Customer experience would suffer significantly due to downtime.

2. Load Balancer Bottlenecks

Scenario:

• If the load balancer is not adequately scaled, it may become overwhelmed during peak traffic times. This could happen if there are sudden spikes in user requests.

Impact:

• Increased latency or timeouts for user requests.
• Potentially more requests being routed to a limited number of servers, leading to degraded performance.

3. Service Outages (Microservices)

Scenario:

• Any of the microservices (Search, Booking, Payment, Hotel Management) might become unresponsive due to unhandled exceptions or resource exhaustion (CPU, memory).

Impact:

• For example, if the Payment Service fails during the payment process, users may not be able to complete their bookings.
• If the Search Service goes down, users cannot retrieve room availability or pricing.

4. Database Bottlenecks

Scenario:

• The shared booking and payment database may become a bottleneck, especially during peak booking times. Frequent read/write operations can overwhelm the database.

Impact:

• Slow response times for booking confirmations or payment processing.
• Increased contention could lead to database locks, further degrading performance.

5. Caching Staleness

Scenario:

• If the cache for the Hotel Management Service is not invalidated appropriately, it could serve outdated hotel data (e.g., prices or availability).

Impact:

• Users might see outdated information, leading to potential overbooking or dissatisfaction due to discrepancies in room availability.

6. Network Partitioning

Scenario:

• Networking issues could cause partitions between services, particularly in a microservices architecture where inter-service communication is critical.

Impact:

• Services may be unable to communicate, leading to failures in booking processes or payment confirmations.
• Data integrity issues could arise if booking services operate independently without synchronizing.

7. Payment Processing Delays

Scenario:

• The interaction between the Booking Service and Payment Service could introduce delays, particularly if the Payment Service becomes slow or unresponsive.

Impact:

• Users may experience delays during the booking process, resulting in potential transaction timeouts.
• This could discourage users from completing bookings, impacting overall conversion rates.

8. Concurrency Issues

Scenario:

• Race conditions may arise when multiple users attempt to book the same room simultaneously, and the solution for handling concurrency is not adequately implemented.

Impact:

• Overbooking could happen if proper locking mechanisms are not in place, leading to frustrating user experiences and potential financial losses.

Future improvements

1. Redundancy and Failover Mechanisms

• Multi-AZ Deployments: We can Deploy our services across multiple availability zones (AZs) or regions to prevent single points of failure. In case one zone fails, the application can continue running in another.
• Load Balancing Across Instances: Use load balancers to distribute incoming requests evenly across multiple instances of our API and microservices to ensure high availability.

2. Auto-Scaling

• Dynamic Scaling: Implement auto-scaling for our service instances and databases to handle sudden spikes in traffic. This ensures that resources automatically scale up during high loads and scale down when the load diminishes, optimizing cost and resource use.
• Monitoring Metrics: Set metrics (CPU usage, memory consumption, request count) to trigger scaling actions.

3. Circuit Breaker Pattern

• Circuit Breakers: Implement circuit breakers in our microservices to prevent cascading failures. If a service is unresponsive, the circuit breaker opens and redirects traffic to fallback mechanisms or default responses, allowing the system to recover smoothly.
• Timeouts and Retries: Configure timeouts for service calls and implement automatic retry logic for transient failures.

4. Database Optimization

• Read Replicas: Utilize read replicas to distribute read load, allowing our primary database to handle write operations, which improves performance and reduces bottlenecks.
• Sharding: Implement sharding to distribute data across multiple databases based on certain keys (e.g., hotel ID) to improve query performance.
• Connection Pooling: Use connection pooling to manage database connections effectively, reducing the overhead of establishing new connections frequently.

5. Effective Caching Strategies

• Caching for Performance: Use caching mechanisms (e.g., Redis, Memcached) to store frequently requested data, such as hotel information and images, reducing the load on your databases.
• Cache Invalidation: Implement clear cache invalidation policies to ensure data consistency, especially during updates to hotel availability or rates.

6. Graceful Degradation

• Fallback Responses: Design our services to provide meaningful fallback responses when certain functionalities are unavailable (e.g., serving cached search results if the live query fails).
• Maintenance Mode: Implement a maintenance mode that enables the application to serve static content or an informative message while important updates are made.

7. Health Checks and Monitoring

• Health Monitoring: Continuously monitor the health of our application and all microservices. Implement automated health checks to identify failures and trigger automated recovery or alerting mechanisms.
• Centralized Logging and Alerts: Set up logging (e.g., ELK stack) and monitoring (e.g., Prometheus, Grafana) to collect metrics and log data to identify issues and trends. Use alerts to notify our development team of anomalies.

8. Stress Testing and Chaos Engineering

• Load Testing: Conduct load testing to identify bottlenecks under expected user loads. Use tools like JMeter or Gatling to simulate high traffic.
• Chaos Engineering: Regularly test our resilience using chaos engineering practices by intentionally causing failures (service shut down, increased latency) in a controlled environment to see how the system responds and ensure proper handling.

9. Data Backup and Recovery

• Regular Backups: Implement regular data backup procedures, and store backups securely in different environments. This safeguards against data loss.
• Disaster Recovery Planning: Establish a disaster recovery plan to quickly restore services in case of serious outages. Clearly outline steps for recovering from different types of failure scenarios.