3

Suppose I have (micro)services:
The following is simplified a lot, you may assume they're significant enough to be a micro.

  • Reseller Service - Our code is turned into whitelabel software. This is the service that owns the Reseller related data, like its ID, name, main brand, active modules etc. Creation and updating can only be done via the API to this service
  • Distributor - This owns the data for distributors, like the name and logo. For now we manage them, but its not unthinkable in the future they might add their own.
  • Insurance - This owns the data for insurances, like the name and max amount. This is just an example extra service to indicate that there are multiple other Services.

We've now came across the following issue: Not every Reseller has all Distributors or Insurances. We need to config what distributors are active for a Reseller and what Insurances are active for a Reseller.

This presents us (afaik) two routes we can take:

  1. Reseller Service with a Reseller table and pivot table reseller_distributor with an r_id and d_id.
  2. Distributor Service with a Distributor table and pivot table distributor_reseller with an d_id and r_id.

There are good arguments to be made for both;
When all things appear equal, how do we make a choice?

Pro Distributor at Reseller: You config a Reseller, which is an important object, and you can do that in one location.
Con: Now the Reseller service needs to know about all Things (at least their IDs).
Con: If you want additional info from the pivot (like active_from) you now need to change the Reseller Service Pro Distributor at Reseller: The Reseller needs to know about a Distributor, Insurance, Example only once, in the pivot column.

We're coming up with good arguments for both routes and we dont really think there is a bad solution*, but still we like to apply good practices :)

* Apart from the ChatGPT solution: Create a new Microservice which only responsibility would be to store the relations between everything.

Improve this question
8
  • What are the user journeys to interact with this data? Is it just a crud database, or is there actual business logic here? If so, what needs to be maintained as invariants and what can be eventually consistent through propogated events? Commented May 1 at 14:28
  • I'd say "mostly crud". The Reseller is a core element in all code, some may have FeatureA enabled and others B, which we control via (simple) settings now. Could also be we need to store a limit (eg max 100 messages of something) somewhere, that might be in the ResellerService too Commented May 1 at 14:45
  • Then why do you even have microservices? Why is this not one big database? Commented May 1 at 14:55
  • 1
    Note that this question concerning the approach to the decision-making process, not recommending which solution should be chosen. Commented May 1 at 15:16
  • @user1937198 I have simplified our project to 3 smaller services for the example, in the actual project each service has a lot more to it :) You may assume its worth turning into a Service Commented May 1 at 15:28

2 Answers 2

Reset to default
6

There are good arguments to be made for both, how do we make a choice?

By choosing the solution that keeps your services independently deployable and scalable. If neither solution achieves that, you'll need to consider other solutions.

At a high level, do your solutions pass this litmus test?

  1. If the distributor and insurance micro services don't exist, can the resellers service still be used?

  2. Can you scale the resellers service without also scaling the distributor or insurance services?

  3. Since the resellers service is white-labelled, can your customer provide their own distributor and insurance services to seamlessly integrate with your reseller service?

If you answer "Yes" to all the questions above, pick the solution that is easiest for your team to implement and maintain. If you answer "No" to any of these questions, you might need to reconsider your design altogether; your services are not independent.

You have an additional level of independence required that other micro service ecosystems don't have: the micro service itself should be capable of being dropped into any arbitrary micro service ecosystem and still function. Sure the other distributor and insurance services need to adapt to your reseller service message structure, but this should be possible provided those other services know the message format your reseller service expects.

Maintaining independence between services should be your focus here. Choose the solution that keeps these things independent, or scratch your existing solutions and find one that does.

Improve this answer
1
  • Thanks for your answer :) After the weekend we're going to discuss this subject and your answer will be a help :) (The answer is "yes" to all 3 questions btw) Commented May 1 at 15:27
1

Choose both

A Reseller knows about its Distributors and vice versa. Unless the microservices are a distributed monolith you need to assume that user won't know about or use both microservices. some resellers or distributors might be on some other company's system. You need that external key and a link to what system its good for.

If you own all the microservices and they make up a big app together, then its a different story. You can choose which relation makes the most sense for the overall solution and implement it only on that one MS. If you need the reverse lookup for some reason then you can always make the extra calls at no cost. You know the info is there.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.