Open RushikeshPharate opened 2 years ago
Thanks Team Zilean for the feedback, The reason for choosing to maintain user data and session logic in same microservice is to save the effort of maintaining two microservices for the related data, as both modules will anyway remain independent during user session, and can communicate to one another without making network calls, when needed.
I agree with Tanu but I think the professor suggested that we should develop user and session microservice differently because that is a scalable design because if in the future you have millions of users then it will distribute load properly
- I think you could have developed asynchronous communication as now your system cannot handle multiple requests efficiently.
We kept this in mind and tested RabbitMQ for asynchronous communication between API Gateway and Plotting Service since those are the most heavy lifters, but due to lack of our knowledge in it we were not able to pursue it. Either way its a good point from a point of scalability, which we'll definitely try to achieve the next time.
I agree with the scalable thing, but multiple network calls can simultaneously make the system very slow and both the data are very inter-related. Professor mentioned we can have two micro services as to show internal communication among them but we are fulfilling the same purpose among gateway and other services.
Thanks for your feedback Rushikesh and Aishwarya!
System design is good and efficient. Also, dockerizing microservice is a commendable task and it works properly. Having user and session logic in one microservice is good but could have made 2 microservices out of it. Actually, both ways are correct but we went with the later one. Below are some observations from our side.
Pros:
Cons:
Thanks Team Zilean