(1) You mean if you define custom Authorizer and ClaimMapper? If so then yes, you would need to.
(2) ClaimsMapper can translate caller identity (from TLS and/or Auth Token).
(3) Yes, tls, see here.
(4) For namespaces, Temporal server does not enforce a max but total number will depend on your cluster capacity.
For workers, you typically want to start with single worker process and saturate it. See worker tuning guide.
There is a couple of key metrics that you can utilize in order to know if you need to increase your worker capacity:
a) Sync match rate (server metrics)
Useful Prometheus query:
sum(rate(poll_success_sync{}[1m])) / sum(rate(poll_success{}[1m]))
poll_success_sync measure only async matched tasks.
poll_success measures how many total tasks are delivered.
Ideally you want sync match rate to be above 99%. If it’s too low it can mean that your workers are unable to keep up and you should consider increasing your worker capacity.
b) task_schedule_to_start_latency (Server metric) , temporal_workflow_task_schedule_to_start_latency (SDK metric)
Measures latency between when a task is scheduled and delivered. If this latency is high its a strong indication to increase your worker capacity (add more workers).
c) asyncmatch_latency
Measures async matched tasks from when this task is created to when it’s delivered, including the time the task is sitting in the task queue. Large latencies can indicate that your workers are unable to pick up tasks fast enough and can be an indication to increase worker capacity.