Answer the question
In order to leave comments, you need to log in
Is such a data exchange architecture normal?
Essence - a site of paid ads for the sale of real estate. Interested in how reasonable it is to use the architecture described below.
The main part of the work on placing ads is carried out by managers from the office, it is also critical that the current database of ads and all payment data be contained in one controlled place. At the same time, some kind of personal account should be implemented on the web for advertisers, where they could edit their ads.
It is proposed to maintain a complete database with all project data inside the office on some DBMS / CRM, and on the Internet to keep only a reflection / mirror of the data necessary for the operation of the site.
Data is synchronized from the database to the web in case of changes, as well as from the web to the database in case of changes by clients from their personal accounts. The process is supposed to be relatively fast (say, a 5 minute delay is allowed).
In the DBMS / CRM, a queue of requests / commands for updating is formed, which are sent to the Internet via the crown. There is a similar queue on the website side, it contains data that has been changed from personal accounts and that needs to be entered into the DBMS / CRM.
Requests in both queues are moved by the launch of worker bots and, depending on the results of execution, are marked as completed/failed. This is done in order not to lose any changes and, in which case, to see which requests did not work both “from above” (from the site) and from below (from CRM).
Files (photos) are synchronized by simple copying, say, via rsync over FTP or something like that.
I don’t want to keep everything (ads, payment data and business logic of mutual settlements) on the Internet: the data is commercially critical. Plus, in case of failures, I would like the office to have an up-to-date data set and you can continue working with it until the connection is restored, after which the accumulated requests would leave the queue for the site.
It is assumed that with such a scheme, a quick relocation of the office and site can be ensured.
So is it ok? Maybe there are some more reasonable practices and solutions?
I would be grateful for any opinions, even purely skeptical ones.
Answer the question
In order to leave comments, you need to log in
Isn't it difficult? How will you synchronize data operations?
It is better to do this: the manager from the office and the user from the Internet work with one web interface (= one program). Accordingly, they have access to the database schema (someone for writing, someone for reading). There are two schemes - one accessible from the application, the second - not. Communication between the two schemes goes on some kind of protocol and only inside. We get: one code for users to work with the database, separation of schemes by access level.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question