System requirements

Functional:

1. User Registration and Login: Allow users to create accounts, log in, and manage their profiles.
2. Search Functionality: Users should be able to search for hotels based on different criteria, such as location, price range, date of stay, and number of guests.
3. Real-time Availability: The system needs to provide real-time updates on hotel availability to prevent bookings for already booked dates.
4. Hotel Comparison: Users should have the ability to compare multiple hotels based on features, prices, ratings, and reviews.
5. Booking Management: Allow users to book hotels, modify bookings, and cancel reservations. Include email notifications for confirmations and updates.
6. Payment Processing: Implement secure payment processing, supporting various payment methods (credit cards, PayPal, etc.).
7. User Reviews and Ratings: Provide a feature for users to leave reviews and ratings for hotels they have stayed at.
8. Personalized Recommendations: Use algorithms to suggest hotels based on user preferences, past bookings, and search history.
9. Admin Panel: For hotel administrators to manage hotel listings, monitor bookings, and respond to user reviews.
10. Mobile Compatibility: Ensure that the platform is accessible via mobile devices for users on the go.

Non-Functional:

1. Performance:
   • The system should handle up to 10,000 concurrent users with a response time of less than 2 seconds for search queries.
   • Booking operations should be processed within 3 seconds.
2. Scalability:
   • The architecture should be able to scale horizontally to accommodate increased traffic during peak booking seasons (e.g., holidays, festivals).
3. Availability:
   • The service should have an uptime of 99.9%, ensuring it's available for users at all times.
   • Implement redundancy to ensure high availability.
4. Security:
   • Implement secure data transmission (e.g., HTTPS) and robust authentication mechanisms.
   • Ensure compliance with standards like PCI DSS for payment information.
5. Usability:
   • The user interface should be intuitive and user-friendly for a variety of users, including those who may not be tech-savvy.
6. Maintainability:
   • The system should be designed for easy maintenance and updates, including automated testing and integration processes.
7. Data Consistency:
   • Ensure data consistency across distributed databases, especially during concurrent bookings and updates to hotel availability.
8. Localization and Accessibility:
   • The system should support multiple languages and be accessible to users with disabilities (e.g., compliance with WCAG).
9. Backup and Recovery:
   • Implement regular data backups and a reliable disaster recovery plan to restore operations in case of failure.
10. Logging and Monitoring:
    • Incorporate logging mechanisms to track usage patterns and monitor for issues in real-time.

Capacity estimation

We have 100000 serach queries per day + 5000 bookings + 5000 paymens + 1000 reviews = 112000 transactions per day. To compute per second we dviide it by the number of seconds in a day, thus 1112000 / 24 * 60 * 60

For data capacity we have a user record = 1kb, with 1000 new users daily

Hotel listing is 10 kb with 50k hotels

Booking record is 2kb with 5000 bookings per day

Review record is 1kb with 1000 review per day.

With this info we can estimate daily data requirement: 1 kb * 1000 + 10kb * 50000 + 2kb * 5000 + 1 * 1000 = 512000kb/day. To have a per year info we multiply it by the number of days = 512000kb * 365 = 186880000 kb/year = 178,2 GB/year

For a server capacity if we have a server that can handle a 1000 concurrect users and we a total 10000 daily users it means that we need 10000 / 1000 = 10 servers per day to handle the maximum load

If we have 20% of daily active as a concurrect users then COncurrect users = 10000 * 0.2 = 2000 users and we would need 2 servers to handle concurrect users

For server storage capacity: if we have a server that can handle 1000GB and we have a yearly 178 GB year we can estimate the number of servers needed = 178/1000 = 0.178 servers. Since we can't have a fraction of a server we need a minimum of 1 to handle the load.

API design

1. 1. 1) User authentication api: an essential api that allows user to login, logout and reset a password. The first api the user will intercat with. Technologies such as OAuth 2.0 or JWT (JSON Web Tokens) could be used for authentication.

b. Booking search api. Provides API to serach bookings based on various criteria such as: location, price, review score and more. Due to the expected huge amount of data and strict latency constaints this api will prioritize availability over consistency and will be paginated, because the results might be too big to fit into the RAM. Includes the functionality to search hotels based on rankings

c. Booking management api. API includes management of bookings such as: book, cancel or modify the booking. This api prioritizes consistency and serialization for many concurrent users as we would like ot have a user be able to book a hotle in a first-come first server manner.

d. Email/SMS notification api for a new available bookings or a status change for existing booking.

Push notifications to send to the users having a mobile app

e.Hotel comparison api. Provides a detailed overview of a difference of multiple hotels

f. Payment api, consists of: 1) Payment gateway that connects payment bakends (banks, web processros) with the app to authorized and process transactions 2) Payment method api. Provides functionality to facilate different types of payments like credit cards, cheques , etc.

g. Compliance api. AN api used to check if existing hotel are real and compliant with regulatory services like medical standarts, existense of a property.

f. Recomender api, includes an api to show hotels similar so search api but the results are based on the history of previous bookings.

Database design

Included as a class diagram:

classDiagram

User <|-- UserDetails

User <|-- Notification

User <|-- PaymentMethod

User <|-- UserPreferences

User <|-- TransactionHistory

User <|-- BookingHistory

User : +int UserID FK

User : +int UserDetailsId

User : +String name

User : +String HashedPassword

User : +DateTime CreatedAt

User : String Email

UserDetails : +int UserDetailsId FK

UserDetails : +int balance

UserDetails : +String Currency

UserDetails : +Coordinates Location

Hotel <|-- HotelDetails

Hotel <|-- HotelReview

Hotel <|-- HotelStatus

Hotel <|-- UserPreferences

Hotel : +int HotelId FK

Hotel : +int RatingScore

Hotel : +Coordinates Location

HotelDetails : +int DetailsId

HotelDetails : +int HotelID

HotelDetails : +int freeSpace

HotelDetails : +Enum roomType

HotelDetails : +bool hasWifi

HotelDetails : +bool hasParking

HotelDetails : +bool hasPool

HotelReview : +int HotelID FK

HotelReview : +String review

HotelStatus : +int HotelID FK

HotelStatus : +int UserID

HotelStatus : +DateTime BookingStartDate

HotelStatus : +DateTime BookingEndDate

Notification: +int NotificationID

Notification: +int UserID

Notification: +int HotelID

Notification: +DateTime CreatedAt

PaymentMethod: +int PaymentmethodID

PaymentMethod: +int UserID

PaymentMethod: +bool isDefault

PaymentMethod: +Enum PaymentType

UserPreferences: +int UserId

UserPreferences: +int HotelId

BookingHistory: +int UserId

BookingHistory: +int HotelId

BookingHistory: +bool isCancelled

BookingHistory: +DateTime BookedStart

BookingHistory: +DateTime BookedEnd

TransactionHistory <|-- PaymentMethod

TransactionHistory: +int LogId

TransactionHistory: +int UserID

TransactionHistory: +int Amount

TransactionHistory: +int PaymentmethodID

TransactionHistory: +DateTime Date

TransactionHistory: +Enum Status

High-level design

1) Client. Represents the browser or mobile app

2) Api gateway. Balances the load of the incoming web request to the appropriate web server to provide low latency for a request

3) Authentication and auth service. Responsible for authentication, session management and access control

4) Hotel service. An aagregate of:

1) HoteListService. Responsible for listing the hotel according to the user defined filters and ranks them based on the highest rank.

2) HotelRecomendation service. Responsible for giving a recomendation of the best hotel possible according to the user preference and booking history

3) HoteLBookingService. Responsible for managing hotel bookins, like booking and cancellations

5) PaymentGateway. Balances the paymen operation between payment backends similar to an APi gateway.

6) Transaction procesor. Responsible for recording the transaction in the system, monitoring it's status and communicating with external payment service

7) External payment service. A service provided by 3rd party that actually executes the payment

8) Notification service. REsponsible for sending various types of notifications from parts of the system to the user using email, sms or other.

9) Monitoring and logging. Responsible for monitoring the state of system components like CPU and memory usage and overall health, collecting logs and sending out notifications paremeters are above prdefined limits

10) User service. Responsible for managing user information like registering a new user, updating emails, blocking users an etc

11) Analytics and reporting service. Service for generating reports, insights about user behavior

12) Caching layer. Caching infrastructure used to cache various amounts of frequently accessed data to provide increased latency using caching tech specifically tailored for particular data structures like: user sessions, logs, frequently accessed booking logs and etc

13) Databse layer. Data storage and persistence infrastrcutrue consisntg of various SQL and NoSQL solutions tailored to a specific data types.

Request flows

Explain how the request flows from end to end in your high level design. Also you could draw a sequence diagram using the diagramming tool to enhance your explanation...

Detailed component design

Payment service: accepts payment requests from users and preforms risk checks for their transactions, also splits the processing among different machines and payment backends. Stores payment events in a database and notifies metrics subsystem about sucessfully executed transactions

Booking service. Manges everything hotel booking related and stores information regrading user activity in the database. Notifies client about the new bookings.

Booking list service. Retrieves the list of bookings based on search criteria and also manages recomender lists that are updated based on user activity.

Payment prvider. Moves money from client account to the bank bank acount over the wire.

Payment Service:

• Responsibilities: Orchestrates the payment process, receives payment events from users, performs risk checks, coordinates payment execution, and updates relevant systems.
• Key Features:
  • Risk Assessment: Utilizes third-party services to conduct risk assessments, ensuring compliance with regulations and detecting fraudulent activities.
  • Transaction Handling: Manages the lifecycle of payment transactions, including authorization, settlement, and reconciliation.
  • Integration: Integrates with PSPs, external APIs, and internal services to facilitate payment processing and data exchange.
  • Event Logging: Logs payment events, errors, and system activities for auditing and troubleshooting purposes.
• Technologies: Microservices architecture, RESTful APIs, asynchronous messaging (e.g., Kafka), database storage (e.g., PostgreSQL), and containerization (e.g., Docker).

Payment Executor:

• Responsibilities: Executes individual payment orders on behalf of the Payment Service, interacts with PSPs to process payments, and updates payment statuses.
• Key Features:
  • Payment Order Management: Stores and manages payment orders, including details such as amount, currency, payment method, and transaction status.
  • PSP Integration: Communicates with PSPs via secure APIs to authorize and process payments, handle redirects for 3D Secure authentication, and retrieve transaction statuses.
  • Error Handling: Implements robust error handling mechanisms to handle communication failures, transaction errors, and retries.
  • Transaction Logging: Logs transaction details, responses from PSPs, and error messages for auditing and reconciliation.
• Technologies: Microservices architecture, distributed transactions, secure API communication (e.g., OAuth), payment gateway integration (e.g., Stripe, PayPal), and logging frameworks (e.g., ELK stack).

Booking Service:

• Responsibilities: Manages client bookings based on booking criteria. Interacts with databases in sync manner to make sure that no double booking occurs
• Key Features:
  • Technologies: Microservices architecture, Sharded DB, SQL

Booking List:

• Responsibilities: Retrieves client bookings based on client filters. Responsible for quick information access in a timely manner with pagination
• Key Features:
  • Technologies: Microservices architecture, Sharded DB, Geo-sharder Database, In memrory cache

Trade offs/Tech choices

Trade-off: Consistency vs. Availability

WE prioritize consistency in our booking system to prevent any double bookings or corrupted bookings to occur. For booking list we prioritize avaialblity as it is most important to show the client a quick overview of the data right now.

Tech Choices: We utilize distributed databases like Apache Cassandra or Amazon DynamoDB, offering high availability and partition tolerance while maintaining eventual consistency to ensure data integrity over time. And for our long term booking storage with a classical SQL like MSSQl or TSQL sharded by hotel location.

Trade-off: Latency vs. Consistency in Booking List

Explanation: We prioritize low latency in booking list to give the client a quick overview of all potential bookings

Tech Choices: To minimize latency, we employ in-memory caching solutions like Redis or Memcached, optimizing performance without compromising on cost-effectiveness.

Failure scenarios/bottlenecks

Network Failures During Booking:

Network failures can disruptbooking leading to booking failures or double bookings.

Strategies to Mitigate Network Failures:

1. Redundant Network Infrastructure: Implement redundant network connections and failover mechanisms to ensure continuous connectivity and minimize the impact of network failures.
2. Transaction Monitoring: Use real-time transaction monitoring systems to detect network issues and proactively address them to prevent booking failures.
3. Retry Mechanisms: Implement automatic retry mechanisms to reattempt booking.
4. Error Handling and Recovery: Develop robust error handling mechanisms to identify and recover from network failures gracefully, ensuring data integrity and transaction consistency.
5. Transaction Queuing: Queue pending transactions during network outages and process them once connectivity is restored, maintaining transaction order and integrity.

Retry Strategies:

• Immediate Retry: Resending the request immediately upon failure.
• Fixed Intervals: Waiting a fixed amount of time between the failed payment and subsequent retry attempts.
• Incremental Intervals: Gradually increasing the time between retry attempts.
• Exponential Backoff: Doubling the waiting time between retries after each failed attempt to prevent overwhelming the system with retry attempts.
• Cancellation: Canceling the request if the failure is deemed permanent or if repeated attempts are unlikely to succeed.

Future improvements

Machine Learning for Fraud Detection:

• Implementing machine learning algorithms for fraud detection can enhance the accuracy and efficiency of detecting fraudulent transactions. By analyzing large volumes of transaction data, machine learning models can identify patterns and anomalies indicative of fraudulent behavior.
• Utilizing advanced techniques such as supervised learning for classification and anomaly detection, alongside unsupervised learning for outlier detection, can improve the system's ability to distinguish between legitimate and fraudulent transactions, reducing false positives and negatives.

Enhanced Security and Transparency:

• Implementing blockchain technology can significantly enhance security and transparency in the payment system by creating an immutable and decentralized ledger of transactions.
• Each transaction recorded on the blockchain is cryptographically secured, providing tamper-proof data integrity and ensuring transparent audit trails for every payment transaction.