One of the early decisions in making Notic Meet was choosing how data would be stored. Traditionally I have opted for MySQL as I have used this for many years, but in the last couple of years I have worked with NoSQL databases, particularly document based storage.
I have grown to really like this approach and because of this, I decided to use it for Notic Meet.
The database of choice is MongoDb. I don’t have experience using it, but do have experience with Cosmos which has some similarities with it.
After deciding the basic feature set for MVP, and after choosing MongoDb, I met with my team member at Notic and we designed what we could of the storage. In short, some of the items we need to store include meetings, users, notes, threads, plus a few more things. I’ll share a more technical post showing the design at a later date.
Our design considers a number of factors which include user stories and how a user will interact with the data, such as what does a user need, what is the best way to get that data, and so on.
As mentioned, we will be using document storage for this project. We will be duplicating some data across documents to speed up access. This will be meta data rather than the full data, meaning that we could potentially get all of the users meetings by just looking at the user model, but as a meeting is opened, it can then grab the contents of the meeting, if needed.
Partitioning will also be used for some types of data to help speed up retrieval.
We both feel that the design is good to go, although we may make minor alterations as needed throughout building the MVP.
We will post regular updates here. Please feel free to comment, ask questions, make suggestions, and sign up for our emailing list if you prefer to receive updates that way.