4

I know synchronous communication between services is an anti-pattern, so I'm searching for a good solution for my use-case.

I have this two services:

  • Location Service that manages users location
  • Score Service that manages users score

Now, I have to build another service: Users Feed Service (UFS). It has to return users near to a given location, ordered by score (descending).

Synchronous solution

  1. Given a location, UFS fetch nearby users from the location service (REST)
  2. For each one of them, it gets her score from the Score Service (REST)
  3. Finally, it sorts the users in memory and return them

What is the alternative? I have been thinking about something like this:

Event queue solution

  • UFS stores users locations and scores in a database, or memory cache or something
  • It listens to changes in a queue to update its data when the score service and location service publish in it

This way, when client request the users feed, the users feed service don't have to perform any network request (it owns the necessary data)

Is this a good solution? How can I improve it? Will it scale to a lot of users?

3
  • Yes, that's a job for a publish-subscribe middleware (that's the term). – Eugene Mayevski 'Callback Aug 21 '17 at 21:37
  • How many users would be retrieved per request? Does latency matters for the UFS? – Laiv Aug 31 '17 at 15:57
  • I have to decide how many users return. I want it to behave as a continuous flow of users that will be shown in a mobile app (infinite scroll list). Latency matters, because, as I said, it will be used by a mobile app (through an API gateway) – Héctor Sep 1 '17 at 6:36
1

You should check this out: http://microservices.io/patterns/data/event-sourcing.html . You indeed can work with events.

You indeed would work it out like this:

  • Location publishes an event to the event store

  • Score listen to the event store, and when receiving the event, handle it and publish it back.

1

Synchronous communication between services is NOT an anti-pattern by itself. It could very well be that in your case a synchronous solution is better than an asynchronous one, due to the additional complexity introduced by the asynchrony.

An overly-chatty solution is quite bad. It would probably be better if the amount of requests between the UFS and the Score Service would be constant per-request, regardless of how many users the Location Service returned.

I'd have the UFS pass the entire list of user IDs to the Score Service, and get a single response, possibly already sorted by descending order.

I'd probably go with synchronous communication, unless the whole process is part of a background operation.

1
  • I'd agree with this. I'd also go as far as to say that there is no reason for this to be a microservices pattern, or if it is then have an aggregate service exposing a "ScoresForNearbyUsers". That way you can do a proper (normal) service & DB query without thrashing the crap out of your web & DB servers. – LoztInSpace Aug 31 '17 at 3:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.