Serverless Microservices By Business Capability - Hotel

Microservices make life simpler. But, just like any other solution, if not done right, they can make life miserable too. In this post, I'd try to explore a few pitfalls and ways to get around. I'd use AWS serverless components all through.

Take an example of a hotel. Say it has:

• 100 rooms, 10 Floors, 10 rooms per floor
• 50 King Bed Rooms, 20 Double Bed Rooms, 20 Twin Bed Rooms, 10 Suites
• 10 Housekeeping Staff who clean and maintain the rooms, 4 Inspection Staff who make sure that the cleaning has been done properly, 1 Housekeeping Manager

Suppose we want to create an API for the hotel to be able to:

1. Fetch the current status of the rooms - whether they are clean, dirty, need inspection.
2. Update the status of a room
3. Assign a housekeeping staff to a room
4. Check the assignments of the housekeeping staff

How can we design a fleet of services to solve this?

This model might work:

Although they all share the same database, each operation is fairly unique in its technicality.

This can be created and maintained by:

• Team A - For the Fetch operations.
• They create an API that returns the room status by room number or all of them
• Team B - For the Room Status update operations
• They create an API that can update the room status of one or more rooms
• Team C - For the housekeeping staff assignment changes
• They create an API that can add or update one or more assignments per room
• Team D - For looking at the housekeeping staff assignments
• They create a service to fetch staff assignments by room or by staff's ID.

The sole purpose of dividing the work amongst multiple teams is to make the architecture and the supporting resources nimble enough for change. Delegating each separate service to its own team (of 6-10 members) makes sure that each service can function and evolve separately while conforming to communication contracts with other services.

Now lets introduce some entropy to the system.

A new set of requirements come up:

1. There can be an additional status for the room - out of order. 
2. An out of order room can't have a housekeeping staff assigned to it.
3. A room status can't change from out of order to clean. It must change from out of order to needs inspection.
4. An alert must be triggered if a room status changes to out of order within a span of a month.

Lets try to solve each requirement point one by one.

1. There can be an additional status for the room - out of order.  - Team B has work to do.
   Team A would not need to do anything as their service should return the additional status.
   Team B would have to include out of order as one of the allowed set of status values for updates.
2. An out of order room can't have a housekeeping staff assigned to it. - Teams B, C & D have work to do.
   Team A would not need to do anything.
   Team B would have to fail an out of order update if a housekeeper is assigned and work isn't finished on a room.
   Team C would have to fail an assignment if a room is in out of order status.
   Team D would need to include work in progress status of the housekeeping for a room within the rest of the response.
3. A room status can't change from out of order to clean. It must change from out of order to needs inspection. - Team B has work to do.
   Team A would not need to do anything.
   Team B would have to fail updates if change from out of order to any other status than needs inspection is attempted.
   Team C would not need to do anything.
   Team D would not need to do anything.
4. An alert must be triggered if a room status changes to out of order within a span of a month.- Teams A & B have work to do.
   Team A would need to include the last modified date of a room status in their service response.
   Team B would have to trigger an alert if the room status changes to out of order within a month.
   Team C would not need to do anything.
   Team D would not need to do anything.

Looking at the above analysis Team B would have the most work to be done and the rest of the teams would have some work to do.

What if we changed the design?

We can clearly see that room status and housekeeping assignments are two different business capabilities. What if we had one service/Team for each of that?

Now we can have one team per business capability and the databases can also be separated. Each business capability can reach out to the other's REST services to get data as needed. This way, Team Green can be solely responsible for Room Status related operations and the Team Pink can be solely responsible for Housekeeping Assignment Related operations.

For the new set of requirements presented above, both the domains would have their own pieces of work chalked out and some amount of interaction amongst them can be achieved via inter-team interactions or by inter-product owner interactions.

The above structure makes the teams nimble to change while keeping enough people around to be able to address changes as they pop up. 

So, the business capability based structure helps in:

• Adhering to to the Common Closure Principle - things that relate to the same thing and that change together should be clubbed together.
• Ensuring inter capability loose coupling.
• Making each team is autonomous. They can make changes with minimal collaboration with other teams.
• Stabilizing architecture as business capabilities are mostly stable in an enterprise.
• Enabling teams in delivering business value instead of technical features.

For very large organizations, business capabilities might end up becoming huge monoliths. That would end up creating the same old monolith specific problems. For such organizations, services by sub-domains would help decompose the architecture to reap the same benefits stated here. 
I would discuss the same in my next post.

Till then, please feel free to reach  out and provide your feedback. Thank you.

I can be reached here - LinkedIn