MongoDB Overview

Love it or hate it, MongoDB has secured the sweet spot of the “go-to NoSQL database” in the startup segment. Some of its features aren’t well-thought, added in haste according to the market demand, which on the other hand highlights the enterprise orientation of the multi-billion company behind it. Unlike SQL, MongoDB comes with relative freedom to do whatever you want with your data. There are tools, that hide this shortcoming, but at least I personally never felt that I trust my mongo instance enough. As I whine, the reader already understands that MongoDB isn’t my first database choice, however, NoSQL databases are popular, and you have a decent chance of working with MongoDB specifically, therefore MongoDB software architecture is relevant and must be discussed.

MongoDB Role in Software Architecture

It does not come as a big surprise, that the role of MongoDB is to serve as a data storage. On the enterprise level, MongoDB usually comes as a shared cluster, with multiple routers and shards, which makes it a reliable and scalable solution. In my experience, MongoDB can provide a comfortable 99.9% uptime, which is enough for most companies. As previously mentioned, MongoDB is first and foremost a for-profit company. It provides a cloud service and lots of extras you can get if you are willing to pay. Working with MongoDB on the application level is easy, its shell and configuration are simple (oversimplified?). If you followed MongoDB’s development over the years, you noticed it has a bunch of SQL-native features retrofitted.