1

We are a fintech startup that trying to re-build monolith php to microservice. As typical web app, we use to manage master data in admin page. How do i distribute this master data through microservice? We build a two API management service. One for the frontend user entry point other for admin/backend user entry point. We create a Loan service for front-end user and an administration service for back-end user. Loan service will use loan promo, city, country data which are also managable from admin servicd. Should we duplicate the model and database of loan promo, city and country from admin service to loan service? Or should we put those master data in loan service? I also read about saga pattern that maybe we can use it. After any update from admin service will trigger update on loam service.

We are still designing and figuring how to implement it best. Any advice or input I really appreciate.

Improve this question
2
  • Why I get downvote?
    – Tania Rida
    Jan 12, 2018 at 12:59
  • 1
    I assume because it is too broad of a question to be answered effectively. I did not downvote... but I will be flagging for closure
    – TheCatWhisperer
    Jan 12, 2018 at 17:34

3 Answers 3

Reset to default
2

The short answer is 'No', you should not just duplicate the data. The right thing to do will depend on how you have designed your microservice architecture. For example, if you were using Domain-Driven Design, you would have a Bounded Context for each service that defines the Domain Model as needed by that service. Data that is changed by other services that is relevant to this service can be consumed by subscribing to the relevant events published by the services that change the data. This article regarding Bounded Contexts in Microservices may be helpful to you.

Improve this answer
2

If you do microservices, you should to identify the authoritative microservice for each various kinds and/or subsets of the data you now have in monolith. Microservices is not just about teasing apart business logic, but the ownership of, the authority to make changes to, and access to the authoritative & up-to-date data as well.

If you replicate all the data among multiple microservices each allowed to broadly update the data, that's not really microservices, that's data replication, which has its own challenges.

In distributed computing, it is ok to have copies of data on one node that is not authoritative for that — in part because any query to a remote machine returns a copy that is potentially stale as soon as it is received. Distributed architecture — as with client-server, microservices, and others involving multiple servers — has to deal with this potential staleness.

Techniques that can be helpful are:

  • timestamps (or version numbers) associated with queried data
  • APIs that are offer robust interactions, for examples:
    • all or non updates that update multiple things or none within a single source
    • conditional updates that abort if versions or timestamps or other expectations don't match
    • carefully arranged eventual consistency
    • distributed transactions as in 2PC
  • timely notifications/events
Improve this answer
0

In my opinion, all the confusion comes from the fact that you want to extract the Admin API from the Loan service. It's perfectly fine to have both the user-level and the admin-level APIs in one service (of course, with appropriate authorization check).

Improve this answer

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