2 Replies - 408 Views - Last Post: 30 November 2018 - 06:37 AM

#1 elektrovert   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 2
  • Joined: 28-November 18

Need some advice about REST service and database architecture

Posted 28 November 2018 - 03:37 AM

Hi everyone,

I'm currently building a web service that allows various file types to be uploaded to a server file system.
The service has it's own database, where it saves meta-data relating to each file. Currently, there are two instances of this service that are running at the same time. They communicate via rabbit mq and can notify each other when they have received a file, so the other can request a copy of thee file to store on it's file system (shared storage is coming, but that's another story).
One of the criteria for this project is that users should be able to review what files are available from two different applications (depending on the purpose and access rights)and then view them, download them, delete them, etc...

Other services/web apps operate in a similar manner, but I'm reluctant to implement it in the same way for a number of reasons:

We are supposed to be moving to a micro service architecture

The way I have been asked to implement it involves adding to the monolith that we're supposed to be breaking up. My service has it's own database, but doing it this way requires me to add to /update a new table in a database that the monolith uses, in order for the web apps to be able to read the data relating to the uploads.

My other apps/service record user input
With the other apps, the user selects files for the service to manage, and that information is stored one db, the service then gets those files, and saves metadata in it's own db relating to whether the files have been successfully saved. this information is then used by other instances to sync their own files. With this new service, the service itself will be pushing the same information to both databases. This feels wrong, there will basically be two databases with the same information, although in the future additional metadata may be saved in the webapp db.

Management say that we don't need this to be a micro-service as it's not going to be a big service. But I'm still not keen, as my last service which wasn't a big service either is now all of a sudden gone from managing 500kb files to 700MB files, and I'm expecting a similar situation here.

I'm building it with spring boot, but excluding tomcat and deploying to wildfly at the moment. This means I can reasonably easily switch it to a micro service in the future if need be.
But regarding the current API functionality.
Is it reasonable for me to ask that the web apps don't go through the monolith api, and instead query an API that I add to the service, and so bypass the need to include any code in the monolith API?
And, if that is the case, is it reasonable to have this service, when it is a micro service, receiving files from one set of clients, and serving metadata to the web apps for end users to review? Or, should that be two different micro services that use the same database?
I hope I'm making sense here. Any advice would be greatly appreciated.

Is This A Good Question/Topic? 0
  • +

Replies To: Need some advice about REST service and database architecture

#2 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6879
  • View blog
  • Posts: 23,337
  • Joined: 05-May 12

Re: Need some advice about REST service and database architecture

Posted 28 November 2018 - 07:53 AM

This is just my opinion, but I think that although almost all of the diagrams of microservices shows that a microservice as having the fullstack as being fully independent (e.g. the microservice has it's own database), I feel that each of the boxes are conceptual, not physical. Given that, if microservice just needs its own table, why spin up a whole new database just to host a table when you can simply add that table to an existing database? Just make sure that you don't setup foreign key constraints such that if/when that new table is removed or truncated that the original primary database is suddenly crippled.

I know that this goes in the face of the microservices claim that you should be able to at a moments notice start up, shutdown, or replace everything within its vertical stack without affecting anything but stop and really think about it:
  • If you have microservices talking to each other ala SOA, then taking out a service affects the system because of the interdependence.
  • If you have a central front end which talks to the independent microservices (ala microservices were originally envisioned), things are still screwed up if one of the services goes down and/or some configuration works needs to be done to point to a new replacement microservice.
  • If you have multiple microservices each independently exposed and it's the client talking to them, things are still screwed up for the client if one of the services goes down and/or the client needs to be told about a new replacement microservice.

All that microservices does is provide more agility for each of the vertical components stacks to move at their own pace through the development lifecycle with less impact on the entire system. Note the keywords "less impact". It's not necessary "no impact". If it were "no impact", then in wouldn't matter if the service existed or not, in which case, why even have the service in the first place?
Was This Post Helpful? 1
  • +
  • -

#3 elektrovert   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 2
  • Joined: 28-November 18

Re: Need some advice about REST service and database architecture

Posted 30 November 2018 - 06:37 AM

Hi thanks for that, yes, the database is not part of the micro-service itself, although it is owned by the service. my concern was replicating data in two places for no good reason, I've since had a discussion and we're not going to add the separate table for the webapp. The webapp will request the data from the microservice.

This post has been edited by Skydiver: 30 November 2018 - 09:17 AM
Reason for edit:: Removed unnecessary quote. No need to quote the post above yours.

Was This Post Helpful? 0
  • +
  • -

Page 1 of 1