Architecting load-ready microservice APIs on AWS Fargate for a national hospitality chain

PROJECT OVERVIEW

ABOUT THE CLIENT

This case study is based on a real VNEXT project. The client's identity and certain project details have been anonymized or generalized for confidentiality purposes.

Our customer builds digital services for a national hotel group, the kind of group where a guest might stay at a different property every week. For a traveler like that, the value of the group is in how little they have to think about it: one membership, one way of checking in, and coupons that follow them from hotel to hotel. Making that feel effortless means that the web, the mobile app, and every front desk all have to draw on the same information at the same moment. Exact financials are withheld for confidentiality.

THE CHALLENGE

Behind a simple experience sits a lot of quiet precision. A guest's membership card has to be valid on the web and in the app. A coupon has to be redeemable once, in the right place. A check in has to be recognized at a front desk that may be in a different city, using equipment that sits on the group's own private network and not on the open internet.

The work also grew in ambition. Beyond providing the core services, our customer wanted new capabilities that tested the platform itself: performance testing, security testing, and a restructured server design that could handle load sensibly as more guests and more hotels came to depend on it. These changes touched the foundations rather than the surface, so they needed careful planning and a clear understanding of how the existing system worked.

Finally, the platform ran on containers managed by AWS Fargate, a very capable environment that rewards good architecture and offers little cover for loose design. Getting the most from it meant thinking about how services scale, how they are secured, and how they are deployed, before writing the code that would run inside them.

PROJECT OBJECTIVE

Our customer wanted a set of API services for its hotels, its guests, and its coupons, designed to serve both its web front end and its mobile app, and then extended with new functions, a unit test suite, and a server structure that could carry load with confidence.

APPROACH AND METHODOLOGY

Turning high level requirements into designs the customer reviews

Our team worked closely with the customer to clarify and confirm requirements, and began from the customer's high level requirements to write the database design and the API specification. Both were submitted to the customer for review before they became code, which meant that the shape of the system was agreed on paper while changing it was still cheap.

Preparing well before the work begins in earnest

We started the engagement early so that our team could become comfortable with the existing source code and documentation before the heavier work began. We also chose people to match what the project would ask of them: a bridge engineer with long experience and strong Japanese to speak with the customer, a senior developer with server experience to work through the Fargate environment, and a test lead who looked into how to test the new performance and security functions and then shared that know how with the rest of the team.

Testing the structure, not only the features

Because some of the new work concerned how the system holds up rather than what it does, performance and security testing became part of the delivery, along with unit tests for the services themselves. The aim was a platform that is not only correct on a good day but also dependable on a busy one.

Keeping communication simple and regular

Slack connected our team and the customer for day to day questions, our own team members spoke directly to one another over chat, and a weekly video meeting gave everyone a fixed moment to review progress and raise anything that needed a decision.

TEAM SCALE

Our team for this engagement numbered eight, combining development, server expertise, and testing.

• Development lead: set the technical direction and reviewed the work for quality and security
• Backend developers: designed and built the customer, hotel, and coupon services and kept the API versions organized
• Quality lead and testers: created and maintained test checklists, ran the tests, and escalated issues with proposed solutions

THE SOLUTION AND TECHNOLOGY STACK

The platform our team built is the part of a hotel group's digital service that guests never see, and that makes everything they do see work.

What was built

• Guest service: handles sign in, password recovery, and the creation and management of a guest's digital member card, including the barcode used at check in
• Hotel service: provides hotel information to the web and mobile apps
• Coupon service: manages the offers that guests receive and redeem
• Check in connection: links the platform to hotel front desks, where a barcode scan identifies the guest, over the group's private network
• Unit test suite: covers the services so that new functions can be added with confidence
• Load and security structure: uses a web application firewall, load balancers, and a restructured server design intended to carry load sensibly

Technology Stack

THE RESULTS

A guest who walks into any hotel in the group is recognized, and the group's apps and front desks speak to the same services.

• One backend for web and mobile: the same guest, hotel, and coupon services serve every channel, so a membership or an offer behaves the same everywhere
• Check in that works at the front desk: a barcode scan connects the guest at the property to the platform over a private network
• A design the customer approved before it was built: the database design and API specifications were reviewed by the customer before coding, which kept the architecture aligned with what the group wanted
• Foundations tested for load and security: performance and security testing, together with a unit test suite, make the platform dependable beyond a good day
• A structure ready for growth: separate services for guests, hotels, and coupons can each be extended without disturbing the others

For a hotel group whose promise is consistency from one property to the next, backend services that behave the same way everywhere are what make that promise believable.