Best Practices for Microservices - 8.0

English (United States)
Talend Data Fabric
Talend Data Services Platform
Talend ESB
Talend MDM Platform
Talend Real-Time Big Data Platform
Talend ESB
Talend Studio

Best Practices for Microservices

In this article, we will walk through scenarios where a microservices architecture is a sound choice and some architecture and design principles that should guide you along the journey of developing microservices. 

There is no agreed state which can be labelled as a "definite or ultimate microservice". Microservices is evolving and maturing day by day.

There are certain principles and use cases that are more susceptible for a microservices architecture. If architected and built correctly, it will provide the most successful architecture to respond to agile and changing requirements.

There are many organizations that have been very successful at deploying a microservices architecture. A few of those successful companies are Netflix, Uber, Airbnb and eBay.

For more information, see

Microservices Use Cases

In this section, we are going to describe some of the interesting and common use cases where microservices are a good fit.

Black-box Migration

A microservices architecture is an ideal use case when we want to improve or replace a monolithic application. Microservices will support the manageability, scalability and development agility that most business are looking for today when dealing with legacy and monolithic systems. Without much interruption in the functionalities of the monolithic systems, businesses can design and build autonomous microservices to replace the system functionalities step-by-step.

Utility Scenarios

Services which are stateless and deliver data based on input should also be developed using the microservices architecture principles.

For example, fuel prices, weather prediction and fare calculation are good examples as utility services.

Autonomous Business Services

There are business services which are autonomous in nature for example, customer service, which handles customer data only. Login service and notification service are not sticky in nature and only deal with their own data with one concern and these should be developed using microservice architecture.

Backend as a Service

Backend service is a type of service that collects data from different services and combines them to deliver a unified data. An example is MVC application, which gathers data from different logical services and combines them to get displayed by user for different navigation selection. This is a good use case for microservices architecture.

Microservices Architecture And Design Principles

Microservices architecture principles define certain requirements and design principles that must be followed to avoid building traditional spaghetti-like black box system. It is very easy to go back to the easier ways of building spaghetti point-to-point integration.

Hence, architects and designers should be pay attention to the principles below.

Single Concern

Single Concern or Single domain is a very important concept for the microservices architecture. One service should deal only with one logical concern. Cross-cutting concerns must be implemented in a way that microservices must not deal with problems outside of their scope.

Database Access

Data sharing is not a good situation for microservices. A microservice should be designed to have exclusive database control. If data sharing is required among different databases, it should preferably be achieved by leveraging the database internal processes.

For example, a customer service should offer all customer functionality and should have exclusive access to customer data (table or set of tables). All other services, requiring access to customer data, should get the data via the Customer Service (which is a microservice here). No other service should get exclusive access to the customer data table or set of tables.


Since microservices are designed to be autonomous and loosely coupled, it is very important to include all the dependencies with them so that they can be easily deployed.

If the microservices need to communicate to external services, then these should communication details shoul not be hard-code and should be designed such that they are fail safe. This is because microservices can be easily evolved and deployed multiple times.

If we deploy another instance of the same microservice in another subnet, or network, we expect the settings and communication protocol to call the external services to be configurable so that we can configure our new instance of the microservice as needed.

Smaller Footprint

Microservices should be kept as small as possible. The whole purpose around microservices is to build fast, autonomous services which are easy to upgrade and deliverable in short iterations. As complexity grows, services should be further divided into services to keep footprint small.

Scalable and Availability

The whole idea behind microservices is to get seamless scalability. Services should support horizontal scaling so that new instance can be instantiated when needed and starts serving in an automated way.

Talend microservices does support health checks which, for example, can be used with Amazon ELB (Elastic Load Balancing) and AWS Auto Scaling Group.


Due to the nature of microservices, they are generally designed within short iterations. The microservices are evolved on an ongoing basis and new functionalities are always being added. It is this very important to keep track of versioning.

We can have several versions of the same microservices running actively so as to allow clients and consumers time to evolve and switch to newer versions of the same service.