Aryatech's Microservice Trek: A Beginning

?? Context

Let me set the context? first —?Arya.ag is an Agri + Fintech Startup. More specifically:

Business Context ???

●????? Arya.ag has a licensed NBFC(Aryadhan) and provides financial services for the Agriculture sector & farmers.

●????? Arya.ag has warehouse networks across India to support Farmers and traders.

●????? Arya.ag provides an ecosystem to support farmers throughout their pre- to post-harvesting journey.

Tech Context ??????

With our rapid growth at Arya.ag , we continued to evolve our monolithic system to support end customers (farmers, traders, etc., representing both demand and supply) and operational users. But we began to see challenges in - Scalability, Data Ownership, Agility, TDD, CICD, etc.

Apart from existing system challenges, we want to evolve our warehouse solution (WMS) into SaaS (multi-tenancy support) and develop it for ease as we experiment with our business models.

??Analysis First

As Principal Architect, the priority was understanding the current business landscape and bringing architecture strategy to break down monolithic systems. So, we begin with a set of questions:

●????? What is business flow? How do we break it into domain and subdomain?

●????? What's data integrity? How does it support business D2D ops & reports?

●????? What are legal & compliance rules to follow?

●????? What is payment complexity?

●????? What are non-business (or tech) challenges?

●????? Data ownership and what should be its boundary?

After analysis, we decided to break down the system using DomainDrivenDesign architecture.

Why DDD? Because we can break systems in logical domain boundaries. The advantage of DDD is that we have a clear boundary of the system, ownership of data and domains are easily testable. Let's look at the other side of the coin: with DDD, you need to understand the Orchestration layer clearly. We decided not to touch our BFF (Orchestration layer) since we wanted to address one problem at a time.

??? Domain Services

After analysing and considering future evolvability, we broke down the existing monolithic system into 11 domain services, defining each service's bounded context and data ownership. Whenever there was an ambiguity about data ownership, which happened in some cases, we went with our experience and put it in one domain service. As in any startup, our DNA recommends to move fast and fail fast!

?? Data Migration

Well, this is a big task, and really, there is no one silver bullet which fit all data migration case. This required extensive analysis of data and better fitment as per new models. Though we are at an early stage, we decided to make a strategy based on data nature or use case to use case.

The Engineering team did a case study for each as to what data models should look like by keeping in mind future evolvability like Multitenancy. Then, we came up with a plan for the first MVP.

In a nutshell, my first principle is to ensure data integrity by design (i.e. make as many restrictions at the database level), but in some cases, we made exceptions for legacy and, hence, put it at the service level.

?? On the Path

●????? In June'2023, we started brainstorming about micro-services.

●????? In July’2023, we started building foundations for micro-services.

●????? In Aug’2023, we identified our first MVP and started building toward that.

●????? In Sep’2023, we delivered our first MVP on the micro-service stack.

Nevertheless, this wouldn’t be possible without team dedication and efforts to embark on this journey, and I would like to thank you, our engineering team (Deepak, Mayank, Ashwini, Udit, Bhupendra, Samveen, Ashish, Manu), Product team (Mohit, Saurabh) and Business Team (Komal, Jogendra).

As expected, some things go as planned, and some do not.

There are a couple of learnings which I will share in our next write-up.