We are about to develop a microservice architecture with azure functions inside azure. We thought about using interservice communication with durable functions. On app site we want to use an async pub/sub pattern to publish request/commands through a single function gateway. This command will be forwarded to other durable functions and processed there. The response to app will be responded asynchronously via signalR.

All data that need to be processed inside not stateless services will be send via EventGrid/EventHub to the specific cloud services via streaming.

The performance of the durable functions for a roundtrip (App-Functions-App) is about 300 ms. Does anyone has some ideas how to improve the performance?

Architecture Overview

  • 3
    It seems to me that almost every design choice here adds latency. How married are you to this design?
    – JimmyJames
    Commented Mar 15, 2019 at 19:51
  • Not very much, we still could change everything, what exactly would you suggest, or where do you see the problems? Commented Mar 15, 2019 at 20:01
  • 3
    Asynchronous designs tend to be more appropriate for optimizing throughput and/or handling handling uneven demand with a fixed amount of resources. What is your performance goal here? Are your trying to improve throughput, latency, or something else like cost per transaction?
    – JimmyJames
    Commented Mar 15, 2019 at 20:20
  • Well the typical answer: all of it! - Latency should be acceptable (a request made by a user should be answered directly). - The idea is to have high throughput caused by huge amount of users. Stream analysis, calculations made on user input, etc. - Cost should be low of course, that is one of the reason we choose azure functions. Commented Mar 15, 2019 at 20:31
  • These tend to be tradeoffs but I'll ask a couple more questions. I'm not very familiar with durable functions but, as I understand it, the main cost benefit of serverless functions is that you don't pay for them when they are not being used. The tradeoff for that has been that there is some latency to bring them up when requests are made. So are you expecting these to be idle and why did you decide on durable functions over stateless functions? Is it for fan-out, fan-in?
    – JimmyJames
    Commented Mar 15, 2019 at 20:57

2 Answers 2


Performance can better be discussed as perceived performance, rather than the time it takes to make a round-trip. Please search for ways to improve a web page's perceived performance, e.g. "Optimistic UI".

If you place user's request as a message in a queue instead of processing it immediately (maybe that's what you have in mind already), you might be able to assume that it will be processed succesfully and upon placing of the message in the queue, you could notify the user of success. Only if the processing of the message is not succesful, which should occur rarely, you can then notify the user that it was failed. Even this can be questioned in which cases it is necessary to notify after unsuccesful processing.


A structured approach to improving performance often involves

  1. Profiling hot spots, for example high CPU usage.
  2. Profiling wait times. You could include a correlation ID to send through the various systems to keep track on what gets processed when and where.

It may be hard to get the full picture running this on the cloud.

Personally, I would say an async event driven model is a mismatch when the user is waiting for a response. Google has an excellent article on what the user's expectations potentially may be. The gist of it is, up to 100ms is an immediate response, up to 1000ms is still good when the user perceives there is a task being executed. I can't see from your model what kinds of operations you are performing (and the boundaries may be somewhat fluid, some users understand searching all your e-mail is work and some won't)

Azure Event Hubs is a big data pipeline - likely a microbatching architecture. Microbatching tends to have higher latencies.

Thinking about how you scale up on an event stream - Microsoft is not super specific on how the auto scale works... and the data will be opaque to you the operator. On the other hand, if you run a request/response pattern fronted by an API gateway, the API gateway's precise function can be to monitor service levels on the various calls.

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.