When we talk about the scope of a microservice, we are referring to the features of an independent software module. The ability of microservices to perform as a nearly-stateless system allows it to be developed independently.
Create a unique service which will act as an identifying source, much like a unique key in a database table.
Have loose coupling with high cohesion
We should create correct API and take special care during integration. The microservices style is usually organized around business capabilities and priorities. Unlike a traditional monolithic development approach—where different teams each have a specific focus on, say, UIs, databases, technology layers, or server-side logic—microservice architecture utilizes cross-functional teams. The responsibilities of each team are to make specific products based on one or more individual services communicating via message bus. In microservices, a team owns the product for its lifetime.
Restrict access to data and limit it to the required level
Maintain a smooth flow between requests and responses.
Microservices receive requests, process them and generate a response accordingly.Easy integration and automatic deployment (using open-source continuous integration tools such as Jenkins, Hudson, etc.)
Automate most processes to reduce time complexity
Keep the number of tables to a minimum level to reduce space complexity
Monitor the architecture constantly and fix any flaw when detected.
Data stores should be separated for each microservices.
For each microservices, there should be an isolated build.
Microservice architecture gives developers the freedom to independently develop and deploy services.
Deploy microservices into containers
The idea is to containerize ‘like’ services and their required assets into a singular package. A container offers an isolated workload environment in a virtualized operating system. By running your microservices in separate containers, they can all be deployed independently.