I am researching architectural patterns for an application I'm developing and a microservice approach seems like it would be a good choice but I am not sure how to handle interactions between the services.

The application primarily deals with users, profiles owned by users, photos, and tags that represent one to many profiles in a photo. There would conceivably be methods to return photos uploaded by a user, return photos that contain a certain tagged profile, etc.

This is my first stab at designing a microservice-based architecture and I come from a monolithic-esque domain model inspired history. In that world, controllers would stitch these domain objects together but I am having trouble wrapping my head around how this would work in a microservcey way.

2 Answers 2


Usually, services call other services when they need to access their data. Each piece of data should belong to a particular service which will be the only entry point to accessing this data and modifying it. Some services will be simple and usually correspond closely to your domain model (e.g. a service for handling users) while others will be high-level and use data from other services (e.g. displaying a list of photos together with information about the users who uploaded them).

In your use case, you should start from the outside and think of what operations you want to make available to your user via an API (if it's a backend service) or what operations should be available in the GUI if it's a web application. Note that the GUI part is often a regular application with its own controllers: operations may be called via REST (like in AngularJS), but these endpoints are desinged only for the GUI application's use and are not microservices in the common sense.

Suppose you want to display photos together with information about uploaders. You could have a user service that returns information about a user given the user's ID and a photo service which can list photos (e.g. by searching by some criteria). The list of photos would contain for each photo the ID of the uploading user. This way these two services are not coupled - the photo service only knows about user IDs but nothing about the user data themselves. On top of these two services you could create a third service with an operation such as "list photos with information about uploaders" which would call the two other services and combine the data they return. Alternatively, this operation could be performed by your web application instead of a service.

  • 4
    This helped me a great deal. I started by writing a couple of UI use cases that would exercise the stack and everything mostly fell into place.
    – anjunatl
    Commented Mar 22, 2015 at 19:58
  • 1
    In this particular example, are we supposed to do eg. 10 calls to the user service to obtain user data if we have 10 photos in our list? Wouldn't it add a lot of overhead? Commented Mar 22, 2017 at 12:08
  • 2
    @rcdmk You can add a REST endpoint which gets a list of multiple IDs as input and returns multiple photos as output. This is often done in practice for performance reasons. Sometimes, API design is a compromise between purity and practical considerations. Commented Mar 23, 2017 at 14:42
  • 1
    @MichałKosmulski I have need to start discussion, but StackExchange design discourage them :) What I don't like about microservice approach in this particular example is that direct query to underlying database (where users and images are stored) could be much more efficient. Imagine if these upstream services depend on other upstream services and so on. Direct query to data store is much safer. just my 5 cents - nothing more. Again I would really like to have productive discussion on the topic, but StackExachange is not good place for that (can you recommend microservices discussion forums?)
    – ajukraine
    Commented Oct 30, 2017 at 21:51
  • 1
    @ajukraine I think there are chats on stackexchange which may be a good place for discussions. As for performance: 1. Microservices do come with a performance cost, and 2. Microservices are good for some situations but not for others. As for dependencies: in microservice archotectures you often make local copies of data and use asynchronous messaging in order to reduce the number of dependencies. It's a real architecture change, not just automatically changing each module of an application to a separate application. Commented Oct 31, 2017 at 13:07

The application primarily deals with users, profiles owned by users, photos, and tags that represent one to many profiles in a photo. There would conceivably be methods to return photos uploaded by a user, return photos that contain a certain tagged profile, etc.

Well, profile service should not work with user object. It may know only the ID of the user for which it is asked to return data, no more. This way you will not require interaction between user service and profile service.

If that doesn't answer your question, could you please clarify it by describing the exact situation you are dealing with?

  • This and Michal's answer helped me understand it but his suggestion helped me map out the services I needed. I was stuck in a mindset of needing to represent a full object instead of just a reference to the object (user object vs user ID). Much appreciated, thanks!
    – anjunatl
    Commented Mar 22, 2015 at 20:00
  • @anjunatl Welcome ;) Commented Mar 23, 2015 at 8:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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