After working on monolith applications long years in collection systems of a big telecommunication company I made a change and started working in catalog development team for a big e-commerce company which only used microservices architecture. The only thing that didn’t change was millions of data to process whether they were payments or products. It is a very well discussed and long going debate to choose Monoliths or Microservices in architectural decisions in software development so I won’t go into detailed comparison but rather give my personal experience about them.

In collection systems there were huge monolith applications where all had their own relational databases with single codebase and a modular architecture. All applications used tens of libraries as which were using in-memory function calls and all the components were tightly coupled. The communication between these huge applications were mostly Jax-ws and rarely queue. After understanding all the components of the application it was simple to develop and deploy. Best part in this applications you didn’t have to duplicate any data and the data was strongly consistent.

But it was difficult to maintain the codebase, also new features and refactoring could be cumbersome. A change made to a small part of the application, required the entire rebuild and deploy. If you needed to scale the application you needed to scale the entire application. And like in our case if the order of the data is very important (payment, cancel, payment case for same invoice) and you have a single queue then you may have a big bottleneck (This bottleneck then solved with Kafka). It was important to test (incuding regression) carefully and deploy the application at night with a downtime. So we could deploy mostly once in a week and it generally required one operation guy one developer and one QA. After the deployment the owner of the application and data was operation team. So development team was mostly working on projects rather than product in mindset.

When I started working for e-commerce company I encountered with different team structures based on product mindset. There are the development team and the product team. Product manager and development team owns generally a single product in full lifetime. Product manager draws product vision, decides new features and priorities; on the other hand development team developes features, ownes data, monitors services with tools and detailed logs. It’s important to be able to detect the failures quickly and restore services. So it is more fault tolerant. All products are divided into components as microservices. These services are generally responsible for single task and store their own data. So more fitting for agile development. It gives technology flexility according to needs. Our services are written mostly in Java, some Go adn NodeJS. Most of our data is kept in MongoDB but we use PostGre in one service. It is not always the case in our services but with right pipelines we should independently deploy these services. It was very interesting to see that our team can make 29 releases in a single month thanks to Microservices enabling easy Continuous Integration and Deployment. Last but not the least advantage, we can scale exactly the required component.

Unfortunaltely there are some downsides with microservices. Designing microservices can be complex. Data can be duplicated and sometimes need to be carried between services. Communication is either establied by REST services or queues. This causes operational overhead, network latency and data is eventually consistent. In our case we generally use NoSQL databases for services so we send data to Google BigQuery and create relational data from different microservices to be able to give reports.

I am sure everyone worked on both monoliths and microservices had encountered different advantages and disadvantages of both systems. Here in this article I wanted to share my personal experience. Lastly I can advice that choice between monolithic and microservices architecture should align with specific project requirements and organizational goals. Al unique circumstances should be carefully evaluated before making a decision.