How and where to resolve foreign key in microservice architecture -


we started splitting big monolith microservices. 1 of challenges come across how , resolve foreign key.

to give better perspective. planning build following microservices. each of these services has own dedicated database in order make services independent.

pricequote service, responsible managing prices based on variant , city

pricequote -----------------------    id(pk) veriant_id(fk) city_id(fk) price 

cardata service, there 3 concerns clubbed in microservice. makes, models, variants

variants ----------------------- id(pk) model_id(fk) name 

location service, states, cities, , areas clubbed in single microservice

cities ----------------------- id(pk) state_id(fk) name 

please me following concerns

  1. is right way of designing microservices?

  2. where resolve variant_id , city_id fks while retrieving price
    quote? inside or outside microservice?. if outside microservice? where?

the granularity looks fine me (segregation-wise). can't see putting location management , price quotes in same service. because tables point others foreign keys doesn't mean should managed same service. looks okay me far decomposition goes.

i'm not sure mean "resolve" , have no details problem domain, not use price quote service having known location and/or variant already? remember we're past "great normalization trend". it's okay replicate little data elements convenience sake when trade-off isolation vs service-to-service run time dependencies. space cheap. example, when price quote initial insert, have add "name" field "id" of cardata should need to. if pricequote service doesn't have name on hand during insert, instead make event based , update asynchronously.


Comments

Popular posts from this blog

php - Vagrant up error - Uncaught Reflection Exception: Class DOMDocument does not exist -

vue.js - Create hooks for automated testing -

Add new key value to json node in java -