How Shiji Group created a global guest profile store on AWS
AWS Architecture BlogHow Shiji Group created a global guest profile store on AWSby Maximilian Schellhorn, Emilia Smolko, Krzysztof Branicki, and Michał Malczewski | on21 OCT 2022| inAmazon EC2,Amazon Elastic Kubernetes Service,Amazon OpenSearch Service,Amazon RDS,Architecture,Travel and Hospitality|Permalink|ShareShiji Group provides global software solutions for the hospitality industry. TheShiji Enterprise Platformenables customers to manage large hotel property portfolios using software as a service (SaaS). Among functionalities such as reservations, housekeeping, finance, and integrations with external systems, the guest profile is a key aspect of the system. Besides personal information (such as name and address) and billing details, the guest profile can include room preferences and entertainment options.A property portfolio can span multiple hotels across the globe, and each hotel location can offer better customer service by consolidating data. Once the guest gives their cross-border data processing consent (CBDPC), profile information can be shared between properties. This provides a centralized and seamless experience for the hotel guest no matter which hotel in the portfolio was chosen.In the following blog post, you will explore the architecture of the guest profile store that replicates the profile across multiple geographic areas. We will review the single Region design first and its infrastructure components and architectural patterns. We will then show the evolution to a multi-Region architecture.Single Region architecture with CQRSThe ability to find relevant guest profile data fast is essential in the day-to-day hospitality business. Therefore, the following architecture uses the command query responsibility segregation (CQRS) pattern to provide high scalability and rich full-text search capabilities without sacrificing performance. With CQRS,writerequests (commands) are targeting a different service thanreadrequests (queries). This allows systems to store an item (such as a profile) in a search-optimized format for servingreads, while providing a simple schema forwrites.The microservices for the guest profile architecture are operated as containers onAmazon Elastic Kubernetes Service (Amazon EKS). Thewritemodel of the guest profile is stored in anAmazon Relational Database Service (Amazon RDS)PostgreSQL database. A separatereadmodel usesAmazon OpenSearch Service. For interservice communication, Shiji runs a self-managed Apache Kafka cluster onAmazon Elastic Compute Cloud (Amazon EC2).The following diagram provides a walk through the single Region architecture:Figure 1. Single Region architecture with CQRSThe front desk employee creates the Guest Profile upon first interaction with the hotel guest (name, address, billing, and room preferences).The request is routed to theKong API Management Solutionthat is running in an Amazon EKS Kubernetes cluster. It acts as the single entry-point to the system. It identifies the type of request by parsing the URL and forwardingwriterequests to theprofile-write-model-service.The service validates the request. It stores the data andProfileCreatedevent in the PostgreSQL database, Amazon RDS.A change data capture (CDC) mechanism publishes theProfileCreatedevent to an Apache KafkaLocal Profilestopic.The profile-read-model-service subscribes to the Local Profiles topic and stores the profile in an optimized read format in Amazon OpenSearch. Whenever the hotel performs a guest profile search, results will now be provided via theprofile-read-model-service.Multi-Region networking setupShiji operates in multiple AWS Regions to provide low latency, regulatory requirements, and resilience across the globe. The previously presented single Region architecture can be replicated to multiple AWS Regions (eu-central-1 and ap-southeast-1, for example). Hotels with a given property portfolio that operate in the same Region can reuse the profile store of the Shiji Enterprise Platform. However, hotels that are being operated in a different AWS Region can be interconnected as well.This is achieved by providing anAWS Transit Gatewayin a separate networking account that connects the different Regions with aVPC attachment:Figure 2. Multi-Region networking setupThe account segregation provides an additional layer of flexibility to add further Regions in the future.Multi-Region event replicationUpon first arrival, guests can choose to sign a cross-border-data processing consent (CBDPC). This permits the hotel to share the profile information globally. If accepted, theprofile-write-model-servicecreates an additionalProfileCreatedevent that gets published to aGlobalProfilesEUApache Kafka topic. This topic is accessible for subscribers in the target Region, which replicates relevant profiles into the local database as follows.Areplicator-servicein the target Region (ap-souteast-1) is now able to subscribe to theGlobalProfileEUtopic in (eu-central-1), via the established network connection from the previous section. It republishes the event to a localReplicatedProfilestopic that theprofile-write-model-servicesubscribes to and saves to the local database:Figure 3. Event replicationPutting it all together: The multi-Region guest profile storeThe following diagram combines all the components from the previous sections. It provides an end-to-end look at the multi-Region guest profile architecture. Due to the event driven nature of the system, the architecture can be extended without changing the initial flow outlined in the single Region design.Figure 4. Multi-Region guest profile architectureIf the hotel guest signed a cross-border data processing consent (CBDPC), theProfileCreatedevent will also be published to aGlobal Profilestopic.Thereplicator-servicein the target Region (for example, ap-southeast-1) subscribes to theGlobal Profilestopic of the source Region (for example, eu-central-1). It then publishes the event to its localReplicated Profilestopic.Theprofile-write-model-servicein the target Region subscribes to the Replicated Profiles topic and records the item in the Amazon RDS PostgreSQL database with information about the source Region. This will initiate the local replication similar to the single Region design, and therefore creates a consistent experience between both Regions.Conclusion and outlookIn this blog post, we showed how Shiji built a modern multi-Region microservice architecture on AWS. You have learned about patterns such as CQRS, which provide a scalable solution for both read and write traffic. We’ve also shown what is needed to interconnect two physically separated Regions. With cross-border data processing consent (CBDPC), you have seen how the ownership of guest data can be secured and utilized. The single Region architecture already provided a solid baseline for this solution architecture. The event-driven nature of the system permitted us to add additional functionality for the final multi-Region architecture.The ability to manage a global guest profile within the main system as well as at the property itself is a huge advantage for enterprise hotel companies. It permits hotels to deliver a unified experience to their guests no matter where the guest is within the hotel or on their journey. Food preferences, spa, room, and more, can all be managed from a single guest profile. This centralized information hasn’t been possible within the hotel’s property management system (PMS) until recently.VisitShiji Enterprise Platformfor more information.Maximilian SchellhornMaximilian Schellhorn works as a Solutions Architect at AWS. Previously, he worked for over 10 years as a Software Engineer & Architect on distributed system design and monolith-to-microservice transformations.Emilia SmolkoEmilia Smolko is a Commercial SA, for CEE in EMEA region, based in Warsaw, Poland. She works with enterprises providing guidelines for their cloud journey. With strong experience in software development and integration technologies, she builds digital transformations. Emilia loves to prove her prototypes and keep her programming skills fresh.Krzysztof BranickiKrzysztof Branicki is Lead Backend Architect in Shiji. He has over 12 years of professional experience designing and developing enterprise line-of-business applications for sectors such as healthcare, e-commerce, transportation, and now hospitality. He is a Software Craftsmanship enthusiast with main areas of expertise being distributed systems, microservices, and event-driven architecture.Michał MalczewskiMichał is a Cloud Architect at Shiji Poland. He gained experience in various IT projects and roles over the past 15 years. As a technology enthusiast, he always looks at problems from different perspectives. Understanding the broader context helps to create solutions fit for purpose. Currently, Michał is focusing on the design of the global-scale infrastructure for the hospitality solutions developed by Shiji.
Shiji Group provides global software solutions for the hospitality industry. The Shiji Enterprise Platform enables customers to manage large hotel property portfolios using software as a service (SaaS). Among functionalities such as reservations, housekeeping, finance, and integrations with external systems, the guest profile is a key aspect of the system. Besides personal information (such as […]
Maximilian Schellhorn
Amazon EC2 Amazon Elastic Kubernetes Service Amazon OpenSearch Service Amazon RDS Architecture Travel and Hospitality