Defining your service boundaries

In a growing organization where things change rapidly with a new problem to solve everyday, it becomes important as a technology implementer to keep design very clean and extensible and more important to maintain that as you add new features. Here we will  touch upon the concept of micro-services and explain a few design principles around defining various responsibilities of micro-services.

By definition, Micro-services are small, independent processes that communicate with each other to form complex applications. The reason micro-service has become so popular lately is because of the flexibility and agility it provides in development of software applications. Typically, in a microservice setup, there are multiple micro-services, each responsible for performing certain kinds of jobs. It's important to understand how to divide responsibilities among multiple micro-services, responsible for providing certain kind of functionality. 

A microservice can either be customer facing or serving another microservice and its responsibilities lie in defined bounded context. A bounded context is core of Domain Driven Design which defines boundaries of microservices within which they operate and their interrelationship.

In an online retail space finance, warehouse and customer serving can be defined as separate bounded contexts. Defining whether new functionality to be added will be part of one service or other is largely defined by their respective bounded context. This decision becomes difficult when a functionality is spread over multiple services and it’s not very clear, which microservice should own it.

Microservices

The idea here is to pass this to microservice which is more close to feature from business objective perspective than data. To explain this, for above example of online retail model with services for Customer, Warehouse, Finance etc, Organization decides to build a feature to notify their customer via Email and SMS, when they are upgraded to privileged member.

Here there are two candidates for feature implementation, Customer microservice and Notification microservice. From data perspective, Customer microservice looks like a choice as it holds the customer related information but from business objective (notify customer) perspective Notification microservice seems to be holds the notification. Here since it's based on an event from Customer microservice, it will be triggered based on that but implementation like when to send SMS or Email will be driven by Notification service.

Another advantage with approach is any change in feature (say send email in some time of the day) is most likely to fall within Notification service boundary. However, Customer microservice is still responsible to pass on membership change information which can be like publishing an update in event-based architecture.

With this one should avoid premature decomposition. In agile development things keeps changing very rapidly and it’s difficult to get sense of how the system will evolve eventually. So breaking it down in very early stage might lead to unnecessary rework in future. Recommendation is to start building the system, with individual module talking to each other and start dividing system into microservices once you are fairly sure on high level boundaries.

You may also chose to divide first based on high level separation which can be further broken down to multiple microservice. Dividing into broader service first also provide better understanding of dependencies within the modules. In example we discussed above on high level we can first think of dividing system into microservices like Finance, Warehouse, Customer etc and when they individually scale you may further want to divide each of these into multiple smaller microservices, say warehouse into Order, Inventory and Shipments microservices, Finance service to Invoicing, Payments etc   .

To summarize, It’s important to plan out initial services’ design well but it is also required to shape them well on on-going basis as new features are added. This is probably one of the many learnings in our experience while building microservices based systems. Which has helped us in keeping the design more extensible and avoids tight coupling among microservices. 

This article has been authored by Lalit Chandnani, Technical Lead, Urban Ladder. 

Lalit is a tech enterpreneur with 5+ years of experience in building websystems. Experienced in development and research, Architecture planning and Guiding & managing tech teams. Over past few years, he has closely worked on product development and web & IOT systems, validating product ideas using right technology set for products.