Search code examples
design-patternsmicroservices

Communication between microservices / responsibilities


I'm new with microservices, and after reading many documentation, I'm still having some doubts about many things. I'm putting an example of what I want to achieve now:

Scenario:

  • Microservice architecture.
  • The FileServer will store files from several sources.
  • Each microservice has its own database.

TemplateService database:

  • TemplateId (PK): guid
  • FileId (~FK): guid
  • TemplateName

FileService database:

  • FileId (PK): guid
  • FileName
  • Path

Use case: A user wants to upload a template to the application.

Questions: (and my ideas)

enter image description here

Who creates the GUID (FileId)?

  1. UI creates the GUID, and calls both, Template Service and File Service.
  2. UI calls Template Service and this service creates the GUID, and then call the File Service

Who deals with the File Server?

  1. UI sends the File directly to the FileServer (or maybe to another service such as FileManager?)
  2. UI sends the File to FileService, and this service store it in the FileServer.

UPDATED: 2018/03/27

So, my new design looks like this for a UserInput SaveTemplate().

enter image description here


Solution

    1. Don't generate your GUIDs on client apps. Its a bad idea because if this is generally business implementation that should be enclosed on your bounded context services. Client UIs should be thin and dumb as possible.
    2. I would suggest you have a file server for both your layer 2 / bounded context APIs. This would make them independent of each other's existence.

    There are also a few stuff that you can improve with this design:

    1. Consider introducing an API Aggregator. An API aggregator would be in charge of implementing request routing from client applications to level two APIs. Doing so would help you encapsulate level 2 (Bounded context services) which gives you flexibility to swap level APIs. Client apps talking directly to your APIs dedicated for your bounded contexts disables you from making autonomous changes on these APIs
    2. Consider implementing a Messaging Saga and Compensating Transactions

    To give you an idea how a usual microservice architecture looks like here is an architecture diagram from one of my designs:

    enter image description here