Can I scale request queuing and worker differently?

Discuss
#1

We are interested in using Temporal as the workflow engine to serve the online customer request. We just start the learning, so bear with me for sec.

  1. Request & reply use case: Our online portal calls bunch of services behind, the front-end will wait until the orchestration complete . then show the result to user. The elapse time is around 5 sec. How to design the system using Temporal for this case? I am worried about the resource being held on the web portal if there are too many request. Is there a way to listen to the completion of the workflow from the requesting side?

  2. Can queuing API and worker API be deployed separately in order to scale them differently? From the architecture diagram (https://docs.temporal.io/docs/server-architecture), it seems API is held together. Our thought is that queuing part should be super fast and reliable, but worker part can be very heavy and slow. By the way, where can I find the info on how to scale Temporal?

  3. security: is there a way to encrypt the data in the database?

Thanks,

#2

  1. I’m not sure that this is a good use case for Temporal. What is expected behaviour if any of the orchestrated downstream services is not available? Is it OK to exceed 5 second timeframe? Is it OK to return error in this case to the client?

  2. Temporal already has multiple roles that can scale independently. So it is possible to scale frontends (that expose API) and matching (that deals with queueing) and history (that maintains workflow state) separately.

  3. We recommend encrypting data on the client. All SDKs expose DataConverter API that can be used to encrypt all the payloads.

#3

Hi Max… thanks for the feedback. Your answer makes me to think the request-reply probably should be within a single microservice boundary. behind the scene this service might use message bus/event stream to clone the data for the performance reason.

With that, It would be great to see more architecture guidance/design pattern using temporal.

#4

I’m not sure we are on the same page. If you are planning to use queue/message bus then Temporal could be a better fit. But as you didn’t answer my question (1) I’m not able to give any concrete recommendations.

#5

My apology for the confusion. To your question, if downstream service is not available, I would say retry 3 times. if it still fails, then I guess we have to tell customer " the process is not complete somehow , and we will get back to him/her." If it is over 5 sec, the front end has to assume the request failed somewhere, and show the same issue message to customer.

My thought is that from user experience angle, we cannot let user wait for even 5 sec. Once the request is submitted, user should be able to navigate to other pages. Once the workflow is done, we need to notify user, either through web UI, or email. Hence asked if notification exists in Temporal.

Thanks,

#6

Then Temporal is a good fit for your use case. Start the workflow when the user initiates the process and let the workflow notify the user through an activity about its state changes.