Menu
Community /Pin to ProfileBookmark– 
@NogDogFeb 03.2018 — #Option C: Don't do premature optimization. Use one (well designed) database, and if/when traffic reaches a point where you're noticing performance issues [I]and you can trace them to the database,[/I] look at options for improving it (whether it's Mongo or some other nosql platform, or setting up one or more read replicas of your MySQL database, leveraging some sort of in-memory caching, etc.)
I.e.: follow the YAGNI principle to keep things as simple as possible (until if/when you find out you actually do need it).
_
How to architect an API first multi app platform?
I am trying to build an API first web app that has two parts:
–
Part A: The Project Management App. This would be built using php/mysql. One of the table in the mysql DB will be the **users
Part B: The online chat App. The users of the project management system will be able to chat among themselves. This will be built using nodejs/mongo. The mongodb DB would store the chat transcripts of each users and so would have a **users**users
Now, i have a couple of questions in terms of the architecture of this app.
Question 1: Is it at all a wise idea to maintain two different sources to store the user’s information? The reason why I wanted to have a replica of the users table in the MongoDB as well is because since there will be too many reads and writes happening in the chat app so its best we use a nosql DB. (Lets assume here that my app will be used heavily going forward)
Question 2: If the answer to Question 1 is “Yes”, how do we make sure of data consistency? I have thought of two approaches to achieve this:
Option A: Since we are using the API first approach, so during the registration of a user when the CREATE user api call is made, it will add the user in both mysql and mongodb databases.
Option B: I setup a cron that will sync the data between the mysql users table and the mongodb users collection periodically.
Can someone please throw some light on this and tell me if my approaches are right and that if I am going towards the right direction.
Many thanks
Sign in
to post a comment1 Comments(s) ↴
0
@NogDogFeb 03.2018 — #Option C: Don't do premature optimization. Use one (well designed) database, and if/when traffic reaches a point where you're noticing performance issues [I]and you can trace them to the database,[/I] look at options for improving it (whether it's Mongo or some other nosql platform, or setting up one or more read replicas of your MySQL database, leveraging some sort of in-memory caching, etc.)I.e.: follow the YAGNI principle to keep things as simple as possible (until if/when you find out you actually do need it).
_