Hi Darren,

Thank you for your thoughtful article! I liked that you used a concrete example throughout the article to explain how one can decompose monolith projects into microservice-powered applications. Just on the writing itself, I think it is great that you considered both angles, showing us the problems, the proposed solutions, as well as the drawbacks! The example is also nicely illustrated via architecture diagrams, from which we can see the difference after the decomposition.

To summarize your article in my own words, I think you made some crucial observations that tightly-coupled, single-codebase applications suffer from

- the problem of scaling individual components ([horizontally instead of vertically](https://www.cloudzero.com/blog/horizontal-vs-vertical-scaling))

- the difficulty to maintain [open close principle](https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design)

- the degrading developer experience due to rising code complexity and confusing ownership

By utilizing a microservice approach, we mitigated some of the issues above and additionally, we get to improve the reliability and performance of the application. Or, at least the freedom to scale up when necessary.

On the other hand, there are some hidden costs to choosing the microservice approach, one of which is the complexity of building up the infrastructure, communication channels, and deployment of specific strategies to manage the individual components.

Reflecting on the article and my recent experience working on microservice-powered applications, I think the following points could be useful to consider before making such decomposition attempts.

- The change in software architecture does not immediately or always make the collaboration process between developers a manageable one. While having separate components and hence the ability to assign components to certain teams or developers can help draw lines between development matters, this may make areas where the components need to interact harder to implement and use. This is because if the individual components do not have a good abstraction, or in some cases, good documentation, developers relying on such components can be frustrated by the restrictions now imposed due to the separation between components.

- The knowledge and usage of container-based technologies could help developers working on microservices set up their environment easily. For example, [dockerizing](https://www.docker.com/) the components and having a [docker-compose](https://docs.docker.com/compose/) file can simplify the commands needed to startup all services. On top of it, using tools like [kubernetes](https://kubernetes.io/) can make deployment reproducible and help with auto-scaling.

Lastly, I am impressed that you linked the repository to showcase the microservice implementation of the e-commerce App! Just a really small suggestion to clean up the code if possible, because I do see a lot of commented-out code that may be removed for clarity:)

Cheers!