1

I'm pretty new to Micro services architecture and trying to learn my way through them and we have a big monolithic application and as a company we want to move towards Micro Services Architecture for easier maintenance and deployments. In the process of that, we are doing a POC for the same. I have a couple of queries on Data replication and design of endpoints.

Lets say we have 3 Micro services for Movies-

  • movie-catalog-service - This maintains the movie catalog with movie_id as primary key. Movie Name, description and availability as other attributes.
  • movie-rating-service - This maintains the movie rating with movie_id as primary key. Movie Name and rating as other attributes.
  • movie-service - This is the service which calls the above two services to build an movie model which is a combination of movie catalog and movie rating.

In the above approach, I have a couple of queries.

  • Do the first two services endpoints be exposes to the UI for CURD operations on movie-catalog and movie-rating. Or Only the Endpoints for 3rd service be exposed for CRUD, which in turn calls the first 2 services to perform the necessary operations.
  • Does the 3rd service need its own data base which acts as an Entity with combination of entities from first two services. Doesn't it cause data duplication.
  • Or the Approach should be the 3rd service is not at all required and UI combines or splits the data to call the first 2 services independently for CRUD operations.

1 Answer 1

0

Don't replicate data. Report data.

The main principle of micro-services is that each service is the single authority. Nothing else gets to act like it knows the current value as well. The current value lives in only one place.

Your 3rd service is an aggregator. It might be a handy abstraction but is not required.

Aggregation can happen client side. Client side shouldn't see direct CRUD access. The client should be using the service as a resource. CRUD should be abstracted away. The client should have no idea if you're even using a database.

While you could run services 1 and 2 on the same database you're loosing one of the best benefits of micro-services: isolation. It's nice when breaking one thing doesn't break everything.

With that in mind: there should be no such thing as movie_id here. Give me movie-catalog_id and movie-rating_id. Movies should be matched based on their unique names unless one service has a report of the others movie names. The one with the report isn't the authority on current movie names. If it can't match based on name it must accept that when it learns about a movie receiving a rating it doesn't count until the catalog says it exists. Which is silly to do unless that's an actual business rule. And if it was I'd argue that you'd likely be better off with one service.

3
  • Thank you for the details answer. I understood that Client side can be the aggregator here. But can you please expand on what you mean when Client side shouldn't see direct CRUD. Client does perform a POST call to movie-catalog-service to create a movie catalog which means client is able to CRUD. Commented Jul 25, 2019 at 3:35
  • @Ganeshchaitanya that already has an excellent answer here Commented Jul 25, 2019 at 3:38
  • Got it now. I understood what you were mentioning now. Commented Jul 25, 2019 at 5:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.