Noted: Micro-services is an enormous aspect of server-side architecture. This section does not give anything about micro-services, it just provide some overview look of what micro-service is and approaches
What are micro-services?
Micro-services - also known as the micro-service architecture - is an architectural style that structures an application as a collection of loosely coupled services, which implement business capabilities. The micro-service architecture enables the continuous delivery/deployment of large, complex applications. It also enables an organization to evolve its technology stack.
Monolithic Architecture vs Micro-service Architecture
Given context: You are developing a server-side enterprise application. It must support a variety of different clients including desktop browsers, mobile browsers and native mobile applications. The application might also expose an API for 3rd parties to consume. It might also integrate with other applications via either web services or a message broker. The application handles requests (HTTP requests and messages) by executing business logic; accessing a database; exchanging messages with other systems; and returning a HTML/JSON/XML response. There are logical components corresponding to different functional areas of the application.
| Monolithic Architecture | Micro-service Architecture | |
|---|---|---|
| Solution | Build an application with a monolithic-architecture, handle everything in one-place from top to bottom in an single binary. Example: a single Java WAR file, a single directory hierarchy of Rails or NodeJS code | Define an architecture that structures the application as a set of loosely coupled, collaborating service. Each service implements a set of narrowly, related functions. For example, an application might consist of services such as the order management service, the customer management service etc.s. |
| System Communication | Hardly not, it's will handle request on seperated processes from start to finish | Services communicate using either synchronous protocols such as HTTP/REST or asynchronous protocols such as AMQP |
| Development Process | Team working on same source base with consistency business logic for whole solution | Services can be developed and deployed independently of one another. Each service has its own database in order to be decoupled from other services. |
Advantages and Disadvantages of Monolithic Architecture
Advantages
Simple to develop - the goal of current development tools and IDEs is to support the development of monolithic applications
Simple to deploy - you simply need to deploy the WAR file (or directory hierarchy) on the appropriate runtime
- Simple to scale - you can scale the application by running multiple copies of the application behind a load balancer
Disadvantages
The large monolithic code base intimidates developers, especially ones who are new to the team.
The application can be difficult to understand and modify.
Overloaded IDE - the larger the code base the slower the IDE and the less productive developers are.
Continuous deployment is difficult - a large monolithic application is also an obstacle to frequent deployments
Scaling the application can be difficult - a monolithic architecture is that it can only scale in one dimension.
Requires a long-term commitment to a technology stack

Advantages and Disadvantages of Micro-service Architecture
Advantages
Enables the continuous delivery and deployment of large, complex applications.
Testing - services are smaller and faster to test
Deployment - services can be deployed independently
Development - It enables you to organize the development effort around multiple teams with independent business logic
Easier for a developer to understand and more productivity
Improved fault isolation. For example, if there is a memory leak in one service then only that service will be affected
Eliminates any long-term commitment to a technology stack. When developing a new service you can pick a new technology stack
Disadvantages
Developers must deal with the additional complexity of creating a distributed system.
Developers must implement the inter-service communication mechanism.
- Implementing use cases that span multiple services without using distributed transactions is difficult
- Deployment complexity. In production, there is also the operational complexity of deploying and managing a system comprised of many different service types.
- Increased memory consumption. Require more computer resource for running a system in micro-services architecture

When to use the micro-service architecture?
One challenge with using this approach is deciding when it makes sense to use it. When developing the first version of an application, you often do not have the problems that this approach solves. Moreover, using an elaborate, distributed architecture will slow down development. Using Y-axis splits might make it much more difficult to iterate rapidly.
Later on, however, when the challenge is how to scale and you need to use functional decomposition, the tangled dependencies might make it difficult to decompose your monolithic application into a set of services.
Some tips for design system with micro-service architect
- Do not approach the micro-service development on very early of projects
- Try to make code clean and independent to avoid challenging source code decoupling
- Choose right time to start decompose your code from monolithic to micro-services
How to decompose:
- Decompose by business capability and define services corresponding to business capabilities.
- Decompose by domain-driven design sub-domain.
- Decompose by verb or use case and define services that are responsible for particular actions (RPC-API standard use case)
- Decompose by by nouns or resources by defining a service that is responsible for all operations on entities/resources of a given type (REST-API standard use case)
How to maintain data consistency:
In order to ensure loose coupling, each service has its own database. Maintaining data consistency between services is a challenge because 2 phase-commit/distributed transactions is not an option for many applications. Simple idea is a service publishes an event when its data changes. Other services consume that event and update their data.