How to validate inter-microservice data and fetch related records?

DevOps AWS
#1

Hey there, new here and looking to improve upon my AWS knowledge and understand microservices a little more :slightly_smiling_face:

I have a hopefully simple question thats making me a little confused.

I’ve been reading on line that it’s not good to allow one microservice to call another due to coupling. This makes sense, but, how would I do something like validate that the passed in ID exists in the other microservice (for example, I am creating a user in POST /user and this contains a country ID, Countries is another microservice, /countries).

In addition to this, how would I return the Country record from countries service when fetching a User from the users service?

#2

Some quick thoughts that might help your mental model:
• For microservices, I always lean on the quote: “Make everything as simple as possible, but not simpler.” Albert Einstein
◦ My line personally for too simple is when I’m spending more time trying to architect than I am coding the solution
◦ You should shoot for modular (I can change X which will be changing all the time without breaking Y which is consistent)
• Usually for me, microservices are all tied into the same database with different access based on the role so they can reference each other
◦ User creation service should be able to read information the Country table but not write to it
◦ Country table should not have access to User information
Hope that helps as a mental model as you get going, I always try to keep in mind that microservices are the actions you want to do and only break up the actions when either one will change and the other shouldn’t or they are completely distinct actions that won’t rely on each other

#3

Nicely put, thanks. So you don’t see any issues with using HTTP requests in User to fetch the Country to add to the response, but not to write anything to it?

#4

Not sure how complicated your project is likely to be, but just bear in mind that if your deployment/management isn’t slick and your team is small then microservices can be a pain.

Ask yourself whether you really need microservices in your life or not: https://www.youtube.com/watch?v=y8OnoxKotPQ

#5

(I’m not saying don’t use them, but lots of people don’t consider the pain they can cause)

#6

I don’t see an issue configuring the User app to be able to read the Country table. Example:
• User service creates a user with the following details and writes the following to the database:
◦ username
◦ email
◦ countryID
• Your UI wants to present the User their information, if it calls the User service and it can only read the User table, it’ll return the countryID, which isn’t a great user experience as they won’t know what countryID is
◦ Option 1 - Have the UI make two calls, one to country service and one to the user service
◦ Option 2 - Have the UI make one call to the User service and let the User service read the country table to join the data and get the country name so it’s presented in a user readable format
• I’d always pick option 2, it keeps the service calls minimized and it holds to the idea that the User service is the go-to for anything user related
To’s point, if you don’t have a big reason to keep the country service outside of this use case for example, it’s fair to merge this all into one to avoid the operational and architectural complexity

#7

As a security person, there are times you wouldn’t want a service to read something directly from the DB and instead go with option 1 and make a separate call to another service but that’ll be the exception and should be done for the right reasons potentially for consistency, architecture or security ones

#8

Yea, I’m aware of the pain of maintaining/debugging microservices, we have a project at my place of work that utlisises a lot of them, which is one reason why it’s something that I am looking to try and get up to speed on.

I agree that countries probaly shouldn’t be it’s own service, I was just trying to come up with a very basic example to try to understand how best to allow services to communicate with each other.

I can imagine, I will have 1 main API which contains things like countries and other smaller attributes and maybe split out the larger things, like search ingestion/retrieval, admin panels etc.