Serverless Microservices By Sub-Domains - Hotels

For very large organizations, microservices by business capabilities might end up becoming huge monoliths. That would end up creating the old monolith specific problems. For such organizations, services by sub-domains would help decompose the architecture to reap the benefits of a nimble and fast team. 

Take an example of a very large hotel. Say it has:

1000 rooms, 

20 Floors, 

50 rooms per floor

500 King Bed Rooms, 200 Double Bed Rooms, 200 Twin Bed Rooms, 100 Suites

100 Housekeeping Staff who clean and maintain the rooms, 

40 Inspection Staff who make sure that the cleaning has been done properly, 

10 Housekeeping Managers

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

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

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

Based on business capabilities, we can potentially create something like this:

This provides services hooked to capability based databases - one for Room Status and Another one for Housekeeping assignments.

What could go wrong?

Since this  a big hotel, room maintenance would need much more automation. For example:

• Whenever a room is marked out of order, a third party system should be informed about it.
• The third party system should inform the hotel when the room would be back in order in such a way that an inspection is automatically scheduled for that room on that date.

We could add this directly to the Room Status service and forget about it. However, that would add to the complexity of that service and would need more people to manage the Room Status service. We would not want to do that - it would make the team unmanageable and push it towards a monolithic form of development and maintenance.

How do we solve this?

What we could do is to break the Room Status domain into multiple sub-domains. Something like this:

Here, we created another service to handle the third party. It can receive notifications via a queue from the Room Status Service, pick up details of the third party (example URL, tokens etc.) from its own database and send across requests to the third party. The beauty of this scheme is that for each third party that is added, till a point of time, we can keep adding new Lambdas for processing.

For the other part of the requirement, not much needs to be done, we already had a service to post housekeeping assignment. Third party can call the same via the API gateway and it can add in an inspection assignment with no agent - a Manager can update and assign an agent when it is suitable.

One of the intents of creating microservices is to enable creation and maintenance of smaller teams (in addition to the ease of maintenance). As long as a set of features are contained within a domain scope and have logically small team, we are good. The moment the team size starts increasing, we should start looking towards decomposing the services further.

In the next post I'd be talking about aggregating and delivering logical business entities from a myriad of services.

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

I can be reached here - LinkedIn