2

We recently started splitting a big monolith into microservices. One of the challenges we come across is that how and where to resolve the foreign key.

To give you a better perspective. We are planning to build the following microservices. Each of these services has their own dedicated database in order to make services independent.

PriceQuote Service, primarily responsible for managing prices based on variant and city

PriceQuote
-----------------------   
id(Pk)
veriant_id(Fk)
city_id(Fk)
price

CarData Service, There are three concerns clubbed in this microservice. Makes, Models, Variants

Variants
-----------------------
id(Pk)
model_id(fk)
name

Location Service, States, cities, and areas clubbed in single microservice

Cities
-----------------------
id(Pk)
state_id(fk)
name

Please help me with the following concerns

  1. Is this the right way of designing microservices?

  2. Where to resolve variant_id and city_id Fks while retrieving price
    quote? inside or outside microservice?. if outside microservice? where?

ssharma
  • 521
  • 1
  • 7
  • 17
  • Microservices should be independent of these dependencies. I guess you have to revisit defining your service layers. Please go through [this](https://stackoverflow.com/questions/43426699/db-design-for-microservice-architecture/43515759#43515759) to know about domain designs in Microservices. – Nitish Bhardwaj Jul 28 '17 at 11:06
  • That seems overly segregated. – plalx Jul 28 '17 at 12:46

2 Answers2

3

The granularity looks fine to me (segregation-wise). I can't see putting location management and price quotes in the same service. Just because tables point to others with foreign keys doesn't mean they should be managed by the same service. So this looks okay to me as far as decomposition goes.

I'm not sure what you mean about "resolve" and have no details about the problem domain, however would you not use the price quote service having known the location and/or variant already? Remember also that we're past the "great normalization trend". It's okay to replicate some little data elements for convenience sake when the trade-off is isolation vs service-to-service run time dependencies. Space is cheap. For example, when the price quote does its initial insert, have it also add the "name" field as well as the "id" of CarData should you really need to. If the PriceQuote service doesn't have the name on hand during the insert, instead make it event based and update it asynchronously.

Gerry Mantha
  • 1,068
  • 7
  • 14
  • 1
    I see a potential down side of denormalization. Both CarData and Location service is kind of master data. Many services would be relying on these services. whenever any change occurs, updating it across micro services would be a tedious job. – ssharma Aug 01 '17 at 04:18
  • 1
    It is the service responsible for its own data itself that's in charge of listening for events that would require it to update or insert the replicated data it needs. Implementing this kind of capability in a dozen or more services is not that big a deal. But if the number is HUGE and the data replicated is BIG and/or complex, then perhaps it's time to revisit the domain boundaries. This might be useful: [The Hardest Part About Microservices: Your Data](http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/) – Gerry Mantha Aug 01 '17 at 15:51
0

imho, the relationships between microservice entities , if they have to be kept, are meaningful to the consumer of those services so either A) A consumer DB keeps them or B) each MS keeps the relationships of who its related to by fkid and fktype.

What B) implies is that a parent entity needs to be aware of what child entities it may be related to and then ask those child entities to provide any relationships to it at runtime.

user21246302
  • 1