Designing services as monolithic while keeping Microservices in sight — Part 1
From the experience, what I have observed is we build technology to cater the needs of our users and business, we think everything is going fine, team is small and things will be ok as is.
As organization starts growing, teams starts scaling, more teams starts getting formed, more products starts getting build, that’s when a eureka moment comes and a need of splitting the responsibilities starts getting felt, splitting responsibility from business as well as technology becomes utmost important.
Let’s take an example of fictitious company Holu — Holu is startup in logistics and e-commerce and handles products of few 100 customers, cron jobs pull orders into the system from different e-commerce stores and then publish the orders to warehouse from where they can be packed and dispatched. There are two applications, one for warehouse team and one for order management both connected to same Backend Application which in turn connects to same database, the database tables are connected and setup in a pure RDMS manner following every details of normalization and application logics are wired in a way where it’s somewhat difficult to identify a boundary between warehouse code and order management code.
Everything is working fine and all days are sunny for 3–4 years and Holu continued building this product, until a day comes Holu got funding of 10 million, went on hiring spree, laid the road map for next 1–2 years, and Holu management also relayed this message to their technical team and then Holu management got a surprise.
Can you guess the surprise that technical team has given?
Let’s find out this in next part here
References —
Image source — https://aws.amazon.com/microservices/
13.100
