Distributed System and Design
If you are reading this then I am sure that you are aware of the microservices, if not then you can read my previous articles. One of the main reasons for microservices is to design and developed a highly scalable, constant and reliable distributed system.
A distributed system is just a metaphor for distributing the responsibility of a task to multiple entities. Just like a Project Manager it represents the dev team and asks the client for their requirements and then it distributes the requirements to different developers are per their expertise. The same kind of thing a distributed system does, all the request comes to a distributed system it just navigates the request to different entities along with it manage the lifecycles and flow of request in the system.
One of the good examples of distributed software is any good e-commerce website like amazon. When you hit a request on amazon it sends the request to multiple microservices i.e inventory, payment, order management, analytics etc and once every microservice completed its work then the GUI microservices respond back to the user
So, why do we need a distributed system?
- Highly Scalable and reliable as compared to normal monolithic systems
- Availability is almost 100 % even if some module is down still the complete website will work
- Easy to handle and develop the code as everything is segregated and we don’t have to take care of the complete website, just the module we are working on is our responsibility.
- With the help of some designing technique, we can handle any number of loads i.e if my today’s request count is 10m requests per day and tomorrow it increased to 100m requests per day then I do not need to worry anything as the autoscaling can save me here.
But what are the main principle and strategies to divide the responsibility of services?
The answer to this question would be one. There is just one principle or strategy I need to follow before making any system distributed and that is is my microservice is serving more than one purpose? if yes then divide their responsibilities. let's say I have a microservice that is responsible for order and payment and if somehow the payment service is down in that case I will not able to even place the order as both the services are tightly coupled. If I make them distributed then even if my payment service is down I can place the order and leave the payment in a pending state and once the payment service is up I have the option to process the payment and confirm the order or reject the complete transaction
But if the distributed systems are so good then we each and every software is not distributed because
- It's not easy to maintain several repos of code, the coordination of different services is sometimes become too hard to maintain
- If the software is relatively small then a normal tight coupled code would be a better approach as the no of transactions are less and in a distributed system, we have to deal with network latency and other glicts, which can hamper the performance
- To maintain a distributed system is sometimes quite costly as compared to a normal system. because for deployment, autoscaling, maintenance, messaging, health check and other things you need a lot of tools like Nagios, Kafka,kibana, docker, Kubernetes, cloud etc(some of them are avoidable) but for a normal monolithic system only your code and a tomcat instant would be enough to go live.
But still the would is moving towards the distributed system and it has the capability to make the system more reliable and scalable
