-1

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 ?

|improve this question
  • If this is not the right platform to ask this question then please suggest me the appropriate one. – yunas Sep 2 '18 at 20:37
  • 1
    it sounds like the two apps are different. I wouldnt go for a multitenant solution. But you dont outline any specific problems, im not sure what advice I could give. good luck – Ewan Sep 2 '18 at 22:09
  • 1
    This whole question is based on the misconception there is "one best system or architecture" for such scenarios. There is not. One has to know the situation in detail, and make decisions where to clean up, where to refactor, which parts to make multitenant, or which parts of the system to throw away and buy a 3rd party solution. And no, I don't know a forum platform where you get a sensible answer, IMHO you need to work this out with the people who maintain the system and know the detailed requirements. – Doc Brown Sep 3 '18 at 5:44
  • @Ewan, they are same but the ranking criteria of property listing can differ. Problem statement is, should we keep one database or two different. One means the "X" engineering team needs to work as well and the Code/DB will be highly coupled but then the DB design should be dynamic. And if two then Y team needs to work and provide either web-hooks or DB-replication process to fetch data from X and update DB Schema anyway to store X's data in it. – yunas Sep 3 '18 at 6:12
  • @DocBrown I appreciate for your opinion, I just want to reach out and see if any one had the similar situation/scenario before and their approach / technique can give better insights. Real time example of my scenario can be seen against Zillow that owns Trulia, Street Easy and 3 more. – yunas Sep 3 '18 at 6:16
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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.