Microservices Architecture – CASE STUDY: MSA for a Hotel Central Reservation System

 

Introduction

This case study is based on a composite of customers in the hotel industry. The specific scenario is a subset of common scenarios encountered within this industry. The mythical business represented here is a mid-size chain of hotels with 50 owned properties, 30 managed properties, and 30 franchised properties. We will call this company One Ten Hotels or OTH. This case study discusses the use of an MSA and how it meets the needs of the scenarios discussed.

Business Scenario

OTH is a mid-size global chain of hotels that has grown large enough that it sees a potential business advantage in creating its own Central Reservation System (CRS). The CRS needs to be:

  • Globally accessible
  • Highly available
  • Easily built and maintained
  • Developed and deployed quickly

A simple CRS system needs to expose the following resources:

  • Hotel Information: Description of a hotel and its rooms including text, photographs, and other media types. The basic form of this resource includes hotel address and contact information. The following resources are directly related to a specific hotel but may be treated as top-level resources or separate services:

—  Hotel Inventory and Availability: Vacancies or unsold rooms during any specific range of dates.

—  Hotel Room Types: Specific types of rooms; for example, King Bed or Double Queen. Some room types maybe virtual such as “Run of the House” which matches any available room.

—  Stay Offers: An offer to stay in a specific hotel and type of room for a specific period of time at a certain price. Stay offers are dependent on the underlying pricing model which in this case is not exposed.

  • Guest Profile : Collected information about each guest including name, address, and phone number. May also provide access to loyalty information, stay history, and credit cards for room guarantees.
  • Reservations: A contract between the hotel and a guest to provide services, normally a rental of a specific type of room in a specific hotel for a specific period of time at a specific price for some time in the future.

The typical work flow for a guest to create a reservation is:

  • Locate and select a hotel available for the desired arrival and departure dates.
  • Select an offer to stay in the hotel at a specific price in a particular type of room. This offer may also include meals or other add-ons.
  • Identify the guest (this may already be done if the guest is logged into the system) and means of guaranteeing the reservation.
  • Complete the reservation and issue a reservation number.

MSA-Based Solution

The CRS requires high availability. Also, since demand for a reservation service varies widely depending on the time of day and the day of the week and month, implementing a dynamically scalable or elastic cloud service should reduce ongoing operational costs. It is also desired to use separate development teams to work in parallel on the core services supporting Hotel Information services, Guest Profile services, and Reservations services and their supporting applications simultaneously. This should accelerate development and delivery times.

An MSA-based solution was suggested to meet these needs. Both the Hotel Information and Guest Profile services can be launched without dependencies on any other components or services. However, a reservation binds the guest with the hotel (and type of room) and impacts the available inventory at the hotel for the period of time covered by the reservation. The application layer normally already has the references to both the guest and the hotel and can easily provide these for a create reservation operation on a reservations service. But when a reservation is created, inventory on the hotel must also be adjusted. Creation of a transaction with dependencies on other services is a violation of the principles behind an MSA.

There are a number of ways to work around the dependency between the Reservation services and the Hotel Information services. In this case, an operation was added to the Hotel Information services to reserve inventory. This operation returns a unique inventory ID and removes rooms from the inventory but does not assign rooms to the reservation. The application layer is required to retrieve this inventory ID from the hotel and provide it to the Reservations service when creating a reservation. If the create reservation operation fails, then the inventory can be returned to the hotel using the hotel’s cancel inventory operation. An asynchronous clean-up operation can be run periodically between the inventory and reservation stores to make certain that all reserved inventory has a reservation and returning inventory with no reservations to the pool.

The create reservation operation (often implemented as a PUT or POST request from the HTTP protocol) accepts the reference to the guest profile of the primary guest, the hotel, and the inventory ID along with arrival and departure information, room types and offers, and other information relevant to the reservation. Since all of the information is provided by the application creating the reservation, the dependency between the Reservations services and the Hotel Information and Guest Profile services is broken and the Reservations services can be implemented as a microservice.

Result

While this case study is presented in a generic fashion, it is based on a real architecture that is currently in the process of being implemented. The independence of the service areas has allowed multiple teams to be brought in to extend the services to areas beyond the ones discussed in this case study. Many services required to support a hotel ecosystem can be implemented independently of the other services in the ecosystem. This allows for rapid development of new solutions. In this case, the rapid development addresses the time-to-market requirements of the organization developing the solution. The resulting MSA solution is also expected to meet the needs for rapidly scaling to accommodate the large number of customers and partners that are lined up to use the services.

Conclusion

By placing the independence restriction on the SOA, in this solution the resulting MSA has enabled:

  • Parallel and independent development and deployment of services
  • Scalability through elasticity

The solution is also expected to be resilient through the elastic deployment of parallel service instances and agile since individual services can be changed to rapidly meet new requirements without impacting other services. While MSA may not be suitable for every situation, it is a compelling choice for problems that benefit from the independence constraint.