DEV Community

Discussion on: Microservice data sharing and communication

Collapse
 
assertnotnull profile image
Patrice Gauthier

REST is for public API but you will spend a lot of time to make it right and you have to generate the doc when it's public.

Message queuing you mean like RabbitMQ? It fills more the need of a distributed event architecture with the help of Pub/sub and other patterns but you can make direct calls with the RPC approach. I'm using that approach for 3 microservice at work also because it will come handy (pub/sub) when we want to get notified by the payment microservice.

For APIs GraphQL is coming as a game changer for publicones because the schema becomes the documentation. gRPC is something to watch for private APIs too.

Also I suggest you only send IDs between microservices. They should have their own databases. You should be able to deploy/update/change a microservice without impacting much the others. At work with this appraoch one of microservices I've created communicates with a 3rd party, keep some data in it's own database and has a very low maintenance. The initial development took me sometime though.

Collapse
 
senornigeria profile image
Adekoyejo Akinhanmi

I am definitely consdering graphQL, however, my thoughts are: regardless of the technology being used the architecture must be well designed for scaling. I haven't implemented graphQL because the design (of my architechure) is far from complete however, I agree that it is going to be a game changer. (I almost can't wait) I haven't really heard of gRPC but I'd read it up and see if it aligns with my situation.

Speaking of sharing IDs between microservices, I quite agree with this but then I'd like to know, would you rather incremental IDs or unique alphanumeric IDs since data sharing is involved? Please provide other options you consider better.

Cheers.

Collapse
 
assertnotnull profile image
Patrice Gauthier

You scale according to what market you look for trying to plan for what will come. "Well designed for scaling" is an imprecice goal. "Well design to handle 10k concurrent user" now you have an idea of what you look for. Then you choose the technologies to reach that goal and a little above.

The design for scaling for 10k and 500k users aren't the same see this:
slideshare.net/AmazonWebServices/s...

As for IDs, in database it's faster to lookup for numeric IDs than string. Using unique incremental IDs is fine. The problem with microservice are many. Latency, input validation, error management, concurrency, transaction, caching.. What happens when: requests are taking too long? What error you return and how you handle them? How long and where do you cache the data trying to solve the first problem?