DEV Community

Discussion on: Microservice data sharing and communication

Collapse
senornigeria profile image
Adekoyejo Akinhanmi Author

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?