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
is right way of designing microservices?
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
Post a Comment