I've recently joined a startup that has, in my opinion, a strange (and inefficient) way to access their database.
Their implementation consists of multiple REST APIs that are exposed to multiple clients, these APIs, according to them, were made with a micro-services architecture in mind, that's ok.
My problem is with the way they access their database in those REST APIs, as they made a centralized "micro-service" (lets call it DB service) that receives HTTP requests with a JSON, this JSON is then translated into a database query, executed and then the results are returned as a JSON in the HTTP response, all REST API's use this service to manage their state.
I think this implementation is bad design because:
- It is adding unnecessary latency to the database queries, as each query of the other REST APIs must go through the DB Service via HTTP instead of executing them with a database driver or with an ORM library, which would be more scalable and performant.
- It doesn't go well with a micro-service architecture as each micro-service must have their own database and not a centralized one.
- Database functionalities must be implemented and duplicated manually in the centralized DB service. For example if I need to use some cursors to stream a big chunk of data, the DB service must support pagination via HTTP.
They justified this design by arguing that the service helped them to decouple from the database and if they just wanted to switch from one database provider to another (e.g mongodb to AWS DocumentDB) they just needed to change the DB service. In my opinion if this was really a problem, it was a better approach to make a shared library that used multiple database drivers under.
As they're currently having a lot of performance issues with this design. My suggestions were to remove the DB Service completely, give a database for each micro-service (or use the same cluster with one logical database for each micro-service) and use the database driver (that could be abstracted with a library) in the backend services to connect to the database. Am I wrong? The development time here is not a factor because the project is in a early stage
UPDATE: I just found the real reason they made the DB service, it's because the project wants to be implemented in a serverless architecture with AWS Lambda, since AWS lambda is stateless, a database connection must be opened for each request. As the databases connections are expensive and limited by a fixed number, the DB service provides the ability to just consume one database connection at the cost of a bigger latency and the overhead of a REST API. I still think this could be mitigated by using a database per micro-service.