Discussion about software architecture

Question

I am rewriting an application for better structuring of it and I have arisen some doubts.

The application is a football betting management system and has a web app for management and a mobile app for betting to be made. So this application is currently used by three different clients and will certainly use more in the future.

I wish that, unlike the current scenario, I didn’t need to repeat code for each of the applications. I would like to have a domain and identify which user is making use of the application based on the subdomain used. For example: usuario1.meudominio.com. Then I would know that the user accessing the system is user 1 and would use a token to access data from it in a common database to all users differentiating the records by tokens.

It would be risky to mix data?

I also thought about actually doing three separate systems and even got to do the draft in the image below. The API bank is an API that will provide me with match data, teams, championships and so on. I imagined the Banco Master as being the database that has all the data in common between all the different instances of the system, in case it would be all that will come from the API. And the other three banks being the banks of each of the instances. I opened this topic to listen to opinions and share experiences of how I can best implement this architecture.

What can I change?

I thank everyone who can contribute.

Obs: I intend to use PHP + Codeigniter to develop the web system and the mobile app will be written with Apache Cordova and the database used will be Mysql.

Answer 1

Legal its maturity to see conflicts of responsibilities between projects/ software. I hope I can use this distrust of yours to recommend you an architectural proposal.

Identification and separation of responsibilities

Identify the services of your solution. But try to see only the business of each, and be blind to the technological part - like codes, domains, databases, etc.

• Platform administrator - create clients, manage accesses, plans, dashboards, etc;
• Customers - each customer will be one clienten.seudominio.com.br.

Each of these two is an independent project. They do not share codes, classes, databases, anything. That’s why they should have autonomy. Your administration should work even if there is no client, and your clients should work even if you take your entire administration out of the air - web and database.

How applications - administration and customers - communicate?

At first analyzed, I would do as follows:

1. Any platform update that is done from administration to customer should be done via Message Queue.
2. All information the platform should collect from the customer:
   • Some information, the customer is who will inform your updates to the administration, via Message Queue.
   • Other, more real team, administration should consume a client API.

IMPORTANT: An application - either admin or client - should never directly access each other’s database. This creates a super coupling, and it’s bad practice.

It would be risky to mix data?

YES. And you already knew that, but you asked for prudence, and that’s healthy: +1 for you.

Each client of yours should be a totally isolated instance. Each of your customers must have an instance of the web application/api, their own database instance, and their own area of Storage file - do not put me client files in the famous folder upload together with the codes of its application, heim?.

I must repeat code for each of the applications?

It was obvious that NAY. All your customers should run the same source code, with the latest update and everything. And this code should be fully parameterizable. From setting colors, titles, images, logos, also as credentials, connectionstrings, Storage Locations, and lastly toggles to enable or not Features, resources, etc.

One Server to Rule them all?

I saw in your drawing that you have a hosted server of everything - web application, api, databases, etc. That’s not cool. The ideal is a server for responsibility. One to host web applications - preferably one for your administration and the other for clients - another for your database, and another for your Storage file. That kind of approche Hamase Cloud First, develop your solution so that it is already shaped to be hosted in the cloud.