6

not sure if my question is explainable enough but I will try to explain it here as much as I can. I am currently exploring and playing with a microservices architecture, to see how it works and learn more. Mostly I understand how things work, what is the role of API Gateway in this architecture, etc...

So I have one more theoretical question. For example, imagine there are 2 services, ie. event (which manage possible events) and service ticket which manages tickets related to a specific event (there could be many tickets). So these 2 services really depend on each other but they have a separated database, are completely isolated and loosely coupled, just as it should be in "ideal" microservices environment.

Now imagine I want to fetch event and all tickets related to that event and display it in a mobile application or web spa application or whatever. Is calling multiple services / URLs to fetch data and output to UI completely okay in this scenario? Or is there a better way to fetch and aggregate this data.

From my reading different sources calling one service from another service is adding latency, making services depend on each other, future changes in one service will break another one, etc so it's not a great idea at all.

I'm sorry if I am repeating a question and it was already asked somewhere (althought I could not find it), but I need an opinion from someone that met this question earlier and can explain the flow here in a better way.

bernadd
  • 660
  • 1
  • 10
  • 19

3 Answers3

6

Is calling multiple services / URLs to fetch data and output to UI completely okay in this scenario? Or is there a better way to fetch and aggregate this data.

  1. Yes it is ok to call multiple services from your UI and aggregate the data in your Fronted code for your needs. Actually in this case you would call 2 Rest API's to get the data from ticket micro-service and event micro-service.

  2. Another option is that you have some Views/Read optimized micro-service which would aggregate data from both micro-services and serve as a Read-only micro-service. This of course involves some latency considerations and other things. For example this approach can be used if you have requirement like a View which consists of multiple of models(something like a Denormalized view) which will be accessed a lot and/or have some complex filter options as well. In this approach you would have a Third micro-service which would be aggregated from the data of your 2 micro-services(tickets and events). This micro-services would be optimized for reading and could also if needed use a different storage type(Document db or similar). For your case if you would decide to do this you could have only one API call to this micro-service which will provide you all your data.

  3. Calling One micro-service from another. In some cases you can not really avoid this. Even though there are some sources online which would tell you not to do it sometimes it is inevitable. For your example I would not recommend this approach as it would produce coupling and unnecessary latency which can be avoided with other approaches.

Background info:

You can read this answer where the topic is about if it is ok to call one micro-service from another micro-service. For your particular case it is not a good option but for some cases it might be. So read it for some clarification.

Summary:

I have worked with system where we where doing all those 3 things. It really depends on your business scenario and needs of your application. Which approach to pick will depend on a couple of criteria like: usability from UI, scaling(if you have high demand on the micro-services you could consider adding a Third micro-service which could aggregate data from tickets and events micro-service), domain coupling. For your case I would suggest option 1 or option 2 (if you have a high demanding UI) from user prospective. For some cases option 1 is enough and having a third micro-service would be an overkill, but sometimes this is an option as well.

xargs
  • 2,741
  • 2
  • 21
  • 33
  • 1
    Excellent explanation, I really like your approaches. However, I have one more question about approach number 2 specifically. Are you suggesting that new third microservice would act as a layer which only aggregate data? So for example, we could implement it as event-driven for example (that new third microservice would be subscribed and listen on events and tickets) and whenever new data is pushed or updated to events and tickets it could receive this new data and cache/store it into own storage type. This way it could have all data prepared in upfront? – bernadd Jun 27 '19 at 16:37
  • 1
    Yes exactly. You would listen to events published by events and tickets micro-services. You could use Kafka or RabbitMq or any other Queue for this. Lets say your third micro-services would be called event-tickets-views micro-service. That micro-services listens to events and constructs a data model which would already be in the form you need it for your specific view/UI. You could use some data storage which is optimized for reads like ElasticSearch, Cassandradb, Mongo or any other which fits your needs. That micro-service would expose an API which would return that model that you construct. – xargs Jun 27 '19 at 17:25
  • 1
    Also this is a typical use case when you design your system using CQRS pattern. You can read more here: https://stackoverflow.com/a/56668521/1775693 I explained how you can split your Domain in micro-services. I will update the answer so you have all in one place. – xargs Jun 27 '19 at 17:25
  • 1
    Thanks a lot, I really understand the approach and possible solutions to this problematic topic now. – bernadd Jun 27 '19 at 17:40
  • :) I am glad I could help. – xargs Jun 27 '19 at 18:39
2

In my experience with cloud based services, primarily Microsoft Azure, the latency of one service calling another does indeed exist, but can be relied upon to be minimal. This is especially true when compared to the unknown latency involved with the users device making the call over whichever internet plan they happen to have.

There will always be a consuming client that is dependent on a service and its defined interface, whether it is the SPA app or a another service. So in the scenario which you described, something has to aggregate the payloads from both services.

Based on this I have seen improved performance by using a service which handles client requests, aggregates results from n services and responds accordingly. This does indeed result in dependencies, but as your services evolve, it is possible to have multiple versions of your services active simultaneously allowing you to depreciate older versions at a time that is appropriate.

I hope that helps.

Mr Slim
  • 1,458
  • 3
  • 17
  • 28
1

Optional Advice

You can maintain the read table (denormalize ) inside any of the services , which suited best. Why? - Because the CQRS apply where needed , CQRS best suited for the big and complex application. It introduce the complexity in your system , and you gain less profit and more headache.

Ashwani Tiwari
  • 1,497
  • 18
  • 28