- From the server side, Temporal server roles are stateless and can be scaled horizontally. Fine tuning performance and decreasing latencies often in addition to fine-tuning server, includes scaling and performance tuning your applications, especially the workers that execute your workflow code. For persistence, Temporal does support Cassandra where you can also achieve horizontal scaling. Making sure you properly scale your persistence is important as scalability of a Temporal cluster depends on “state transitions” (db updates/second).
You should be able to achieve very low latencies depending on your setup but you do of course need to run load testing and the fine-tune things accordingly.
-
Yes, you can introduce changes to your workflow code (orchestration logic) without affecting running executions via versioning for example. Temporal also allows you to async update the workflow state via outside events - signals.
-
Yes you can call external apis via activities. Activities can be invoked sync or async. The actual implementation of calling external apis can be as you wish (you control the code).
-
You can execute very large numbers (some uses cares have hundreds of millions) concurrently running workflows and they can have different workflow types.
-
With Temporal a workflow execution is not tied to a particular worker. A workflow execution is specified to a namespace and a task queue. For your user case I assume you wish to have a task queue per merchant, assume because you would want to apply different rate limits? Please describe your use case if you can for this requirement.
As far as workers goes you would want to have multiple worker processes (pods for example) for resiliency and fault tolerance. If one worker process (pod) goes down your executions would be able to continue on a separate worker. Typically you would want to start off with a single worker per task queue and then scale up your worker fleet according to observed SDK and server metrics. More info here and here.