Splitting application into multiple but keeping database same

Question

I have a medium scale e-commerce application. Over a period of time our monolithic project got quite heavy in terms of code base. I was exploring the solutions for it and found micro-services is one option but found it like a very early optimization which involves too many risks and increased development cycles. So, I thought of splitting the monolithic app into multiple apps based on business. I come up with following three:

1. Storefront (Website)
2. Admin Backend (CRM, Reporting etc.)
3. Seller Platform

By creating these 3 separate projects, I find following benefits from this:

1. They we can independently developed them and wherever a common code base is required, we can add them as library in current projects. B
2. These applications can be deployed independently.
3. Wherever we need to communicate between applications, we can write limited APIs to transfer data
4. Having common database will enable us to keep complete consistency of data by retention of all foreign keys

Having said so, I am concerned about following points:

1. Firstly, is this a right approach? Are there any caveats in it?
2. Will having a common database accessed by three apps and writing on similar tables will cause any issue later on with scale?

Answer 1

Microservices have their own set of challenges. What you are describing is essentially using the Strangler Pattern to replace the old application. This gives you some benefits:

• You focus your efforts on one change so you can get the balance of functionality across your microservices correct
• You keep the data store working which was working before

However, it does have some limitations:

• Your bottleneck is now your data store
• Scaling your application is limited to the database architecture

So, I would say it's an effective way to split the complexity of the changes you need to do. The question is whether you understand where your current bottlenecks are for your application.

If you are nowhere near the limits of your current database architecture, then I would power on with your approach as the initial cut. It allows you to focus on the complexity of getting your microservice infrastructure working together without worrying about how data is stored. You can leverage a lot of existing code that handles the database interaction.

That buys you time to consider what changes you need to make.

• Measure your application so you understand the bottlenecks
• Use doctrine (all the "rules" for microservices) as a guideline to evolve your architecture
• Decide what changes are appropriate to address the rate of growth for your system.

In short it doesn't have to be perfect right off the bat. It just needs to be good enough to focus on what the next biggest problem is. And know that microservices bring with it a complexity you won't have in a monolithic application. However, they solve a problem that monolithic apps don't have--one of serving customers at internet scale.

Answer 2

In order for this to be considered a proper microservices architecture each app needs data-autonomy. Without that, you still have coupling between the applications via the database schema.

Whether you need a full-blown microservices approach here is something you need to decide. This could be a step in that direction but you need to realize that you will not have loose-coupling at the degree that microservices provides. The database is a common dependency.

You list "Having common database will enable us to keep complete consistency of data by retention of all foreign keys" as the benefit of keeping a common database. To go to a true microservices model, you will have to stop depending on the database to ensure consistency and solve that in another way. The most straightforward approach is for each app to keep track of the published keys maintained by the other apps in their database. Basically the same thing but you lose the DB's constraint checking functionality.

Answer 3

I understand you are trying to find a solution for your big monolith problem, and splitting it into several different apps with a shared DB is not a bad approach, but that doesn't necessarily turn them into microservices:

See: https://martinfowler.com/articles/microservices.html

As mentioned before, besides other characteristics, a microservice needs to have its own way to manage data. Think about the products not projects idea: a microservice needs to be agnostic of usage, and be able to do one thing, and one thing only. So, completely independent. Microservices might not be what you are looking for but good old SOA: what you want can be accomplished with a service as the gateway to your centralized database. You can even have each application have its own backend service, for separation of concerns.

And keep in mind that going from a monolith to a distributed system (especially microservices) will require you to face a whole new set of issues, from logs to tracking, unit testing, deployment strategy, transactions, and the added complexity to the code itself.

Answer 4

If you can truly deploy each web application without deploying the others, then splitting them up into separate applications is beneficial. If you must deploy 2 or more of the applications at the same time then the very reason you gave for not moving to a micro services architecture will manifest itself when deploying the web applications.

You said:

I was exploring the solutions for it and found micro-services is one option but found it like a very early optimization which involves too many risks and increased development cycles.

Even with three separate web applications, which are really just "small monoliths", you will have these same problems.

You commented:

Yes I forgot to mention that, we already have APIs built in our current web app for mobile apps (Android, iOS). And as per new design they will go in Storefront app

You already have iOS and Android applications. Sitting in production right you've already got 3 user interfaces:

• The monolith web application
• Android app
• iOS app

And you want to add 2 more web user interfaces, which would make your true list of UIs:

• Storefront web app (talks to admin app)
• Admin web app
• Seller web app (talks to admin app)
• Android app (talks to storefront app)
• iOS app (talks to storefront app)

On a related note, all paths lead back to your admin web application (Android talks to store front, store front talks to admin). Your admin application is indirectly being hit from 3 public facing user interfaces (web, iOS and Android). Better make the admin app resilient.

In the very least, separate the data APIs from the user interface applications. Making API calls to your store front app for data just means your storefront application, which is already going to be big, complex and ever-changing, will have yet more reasons to change.

If now isn't the time to go full blown micro services with multiple databases, then I don't know when it will be.