1

I'm solving the communications between the microservices with messaging-architecture.

Let's say I have a tradition application, and there're User, Post Video modules.

You can create the posts, videos with it, but before that, I need to convert the username to user ID.

enter image description here

Once I've split the modules to microservice, I cannot chain them together, we visit the microservices directly instead.

enter image description here

And if I want to convert an username to an ID,

I can call the User service in the Post service via Messaging, so far so good.

enter image description here

But here's the problem:

  • How do I receive the converted user ID? Send another message back to the Post service and continue the next step?

  • What if I want to do this from the Video service? I'll need to make another function for it in the User service?

That will be a lot of the functions if I got more and more services right?

I think this is not how messaging architecture works, but I have no clue how to communicate with the other services without messaging.

(Or should I chain them together in the API Gateway so I don't need the messaging architecture?).

enter image description here

Community
  • 1
  • 1
Yami Odymel
  • 1,782
  • 3
  • 22
  • 48
  • I'm not sure if I understand your question correctly, but have you considered using the reply-to pattern? http://www.enterpriseintegrationpatterns.com/patterns/messaging/RequestReplyJmsExample.html – Riaan Nel Dec 26 '16 at 10:01

1 Answers1

1

From what I understood, you have 3 services: User, Post, Video. In Post and Video services you need to implement commands that will have username as an argument, but not userId. And because all data in those services correlated by userId, you thinking about calling user service first to ask for related userId.

The answer is: you should save username-userId association in every service that requires this.

In your specific case, both Post and Video services should subscribe to NewUserRegistered event from User service and maintain their own username-userid map. This allows you to avoid an extra call to User service from other services.

IlliakaillI
  • 1,510
  • 13
  • 25
  • if I have 1,000 users, I'll have to store them in each of my service(_each service owns a database_), so `1,000 * 3`(User + Post + Video), there will be a lot of the duplicated rows right? – Yami Odymel Dec 27 '16 at 21:09
  • 1
    yes, denormalization and duplication of data is a common practice in distributed systems. – IlliakaillI Dec 27 '16 at 21:14
  • 1
    but you not duplicating all data, only the one that you need in each specific service. In your case it is just 2 fields from users table – IlliakaillI Dec 27 '16 at 21:16
  • And there will be a lot of the duplicated functions like `convertToID(username)` in my services (_`Post`, `Video`_)? Shouldn't this be the `User` service's job? – Yami Odymel Dec 27 '16 at 21:20
  • 1
    it definitely may be User service's job, but you will pay for it with higher coupling, longer response times, the overall fragility of your solution. Because you DON'T want to end up with [something like this](http://www.grahamlea.com/wp-content/uploads/2015/03/Fake-Architecture-Diagram.png). Just try to avoid single points of failure, this will be a good approach to building high availability systems. – IlliakaillI Dec 27 '16 at 21:25
  • LOL sure, I totally understand what you're saying, I'm just keep asking myself: "_Is this really micorservice-ful _". So do you think that a service can communicate with another service (even via a gateway), or there should be **only** one-way communication(ex: event broadcast) in microservice architecture? – Yami Odymel Dec 27 '16 at 21:59
  • 1
    I think that anything is possible and we should never say never, but it is always good to understand consequences. I personally trying to limit communication between microservices only through an async messages, as it increases fault tolerance. You can do it either way but there is always price to pay ;) – IlliakaillI Dec 27 '16 at 22:06