What is the best Architecture / System Design to launch same app in different flavor and a bit different logic?

Question

There is a company let's say "X" which mainly deals in Real Estate / properties and has a website (online portal) to display those properties.

Just like any other big company when they saw a competitor they acquired it and let the legacy of competition intact between the sister companies so that the business grows and the ultimate benefit will go to the parent/head company.

Now consider "X" acquired "Y". X's management then took the decision to use X's source code by revamping UI and quickly relaunch Y in market, oh and yes with same database and introduce a new value/column to differentiate between sources/apps to record activity of both portals. ( This is because Y's management didn't sell code or database but just the name / SEO).

X's product management team decided to use Y to target those area where X is weak so that Y will get stronger on those area and compete with the rest. This change will require App level logical changes / tweaks in codes. Ps. X will feed Y with new leads / property records as an aid to get an edge over other competitors.

The problem which engineering team is facing is:

1. Source code is a legacy code and is not up to the mark

2. X's data is already too large ( let's say 10M+ records )

3. Database schema/structure is a complete mess!

4. Engineering team never got a chance to clear the technical debt and they don't see it either in near future.

Ps. some business level decisions / logics like: X will have it's own users and Y will have it's own users ( means you have to signup at Y to post your property or get the app specific stats, though X's user will be given leverage to post stuff on Y without signing up and that needs to be handled in app's business logic.)

As an engineer, I see 2 options. Either to go in single-tenant fashion or Multi-tenant. Instead I share my opinion, I would like to know the best strategy / Architecture|System design that should be used in this scenario. What should be done for low coupled and easy to maintain code and cost effective approach ?

Answer 1

According to your narrative, I understand the following requirements:

• X and Y will continue to be operated as 2 companies under 2 brands
• There are 2 product management teams, apparently having some autonomy on their approaches, and so on the data
• "X will have it's own users and Y will have it's own users"

I also understand that the following analysis conclusions were already drawn:

• The data structure for both companies is close enough to merge everything it in a single database
• There could however be some differences in the processing, because each record is assigned to the owning system.
• One single team is in charge of the system(s)

All these elements suggest the to go for a multitenancy approach:

• the ownership of data and independence of companies is guaranteed (important if later on is sold to another investor)
• the engineering and support can be streamlined, because in reality ther's one system with some variants
• multineancy allows for tenant-specific customizing. But this has to be engineered properly from the beginning.

I found no argument for a single-tenancy approach (but may be there are and you didn't tell).

Unfortunately, it is not possible based on the information provided to tell more about the architecture and make further recommendations.