Springboot microservices managed by Temporal.io + RabbitMQ

Community Support
4

If there are no legacy requirements I would strongly recommend not introducing RabbitMQ or any other additional queue into your architecture. Temporal already dispatches activities through internal task queues. Here are some benefits of not using an additional queue:

  • Simpler and more available system to install and maintain as it has fewer moving parts.
  • Timeouts. Temporal has separate timeouts for how long an activity task can stay in a task queue before picked up (ScheduleToStartTimeout) and how long it can execute after received by an activity implementation (StartToCloseTimeout). If an external queue is used then it is not possible to control these timeouts separately. So with native task queues, you can specify very long ScheduleToStartTimeout and a short StartToCloseTimeout which would allow you to not fail the task if a downstream service is down for a long time.
  • Retries. Activity invocations are automatically retried according to configured exponential retry options. Each activity type or even invocation can have its own retry options. You are not getting such auto retries when using an external queue. Auto retries do not write anything to the workflow history. So they can have practically unlimited duration. It is OK to retry for days or even months. RabbitMQ has built in retry mechanism, but it uses the same timeout for all activity types, doesn’t support exponential backoff, and is limited in duration.
  • Simpler workflow code. Your workflow code becomes much simpler as no signals are needed. Just activity invocations:
  activities.callFirst(...);
  activities.callSecond(...);
  activities.callThird(...);
  • Rate Limiting. Temporal task queue support rate-limiting. So if there is a need it is possible to limit rate of dispatch of tasks even in the presence of multiple downstream consumers. I believe RabbitMQ doesn’t support such a feature.
  • Heartbeating. You can have long-running operations implemented through RabbitMQ, but they would require a long timeout to detect their failures. Temporal supports heartbeating for long-running activities. This allows quick detection of process outages and other issues even for very long activities. It is also possible to include some application specific information into the heartbeat. If an activity fails and is retried the information from the last heartbeat can be used to continue activity work from the position recorded in the last heartbeat.
  • Cancellation. Temporal activities support cancellation (if heartbeating). It is not possible to cancel a task dispatched to RabbitMQ.

WorkflowID

Would you explain the use case. Are you going to have a single workflow instance only? Or you will have an instance per business entity?

2 Likes