I think I would consider synchronising them with a messaging queue. It's very tempting to use HTTP/REST (easier and faster) and I do use it.
It scales well for a while but I think it gets more difficult when you have A LOT of microservices or you want test the system and all the interactions between them.
Anyhow carefully designing, regardless of the communication system, it's paramount.
Definitely do not share the database between them, don't use the DB as the synchroniser, sends messages and keep storage local to each service.
Hey rhymes, thank you for your answer. I am definitely concerned scaling and I am really trying to make well informed startup decisions. Also, you've mentioned something I have been pondering which is testing? If you don't mind, how would one go about testing. For example, I want to unit test each function within a microservice but then I run into challenges and I end up going the whole nine yards i.e. integration testing, because a function might depend on an another microservice for data. As such, I get confused on how to isolate it. I would appreciate if you can provide insights on this as well.
Hi Adekoyejo, I'm honestly not an expert on this topic but I think the hardest thing is testing interaction between multiple services.
As you mentioned each service (which is a self contained app) should have its own unit and functional testing but you still need to test service A talking with B.
I would research the literature on it. Check Martin Flower's website and these resources:
Setting up integration testing seems also a really good way to design and discuss service boundaries. How would the client consume service A and B? Do you need A and B to then call service C? Do you have all services behind a single gateway so that it's transparent to the client?
There's no easy way to do microservices, that's for sure.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think I would consider synchronising them with a messaging queue. It's very tempting to use HTTP/REST (easier and faster) and I do use it.
It scales well for a while but I think it gets more difficult when you have A LOT of microservices or you want test the system and all the interactions between them.
Anyhow carefully designing, regardless of the communication system, it's paramount.
Definitely do not share the database between them, don't use the DB as the synchroniser, sends messages and keep storage local to each service.
Hey rhymes, thank you for your answer. I am definitely concerned scaling and I am really trying to make well informed startup decisions. Also, you've mentioned something I have been pondering which is testing? If you don't mind, how would one go about testing. For example, I want to unit test each function within a microservice but then I run into challenges and I end up going the whole nine yards i.e. integration testing, because a function might depend on an another microservice for data. As such, I get confused on how to isolate it. I would appreciate if you can provide insights on this as well.
Cheers.
Hi Adekoyejo, I'm honestly not an expert on this topic but I think the hardest thing is testing interaction between multiple services.
As you mentioned each service (which is a self contained app) should have its own unit and functional testing but you still need to test service A talking with B.
I would research the literature on it. Check Martin Flower's website and these resources:
Pattern: Service Integration Contract Test
Spotify's Testing of Microservices
Setting up integration testing seems also a really good way to design and discuss service boundaries. How would the client consume service A and B? Do you need A and B to then call service C? Do you have all services behind a single gateway so that it's transparent to the client?
There's no easy way to do microservices, that's for sure.