Temporal Process
You set up a temporal process by running worker code that polls a central server. The server tracks each step in an event log so failed tasks resume right away. Teams often build these background workflows with shared service keys and broad database roles. When permissions are too wide, one bad task or debug command can alter live data. How a temporal process works in your architecture A temporal process splits your job logic into two main parts. The first part is the workflow, and the second
Process: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a temporal process by running worker code that polls a central server. The server tracks each step in an event log so failed tasks resume right away. Teams often build these background workflows with shared service keys and broad database roles. When permissions are too wide, one bad task or debug command can alter live data.
How a temporal process works in your architecture
A temporal process splits your job logic into two main parts. The first part is the workflow, and the second part is the activity. Your workflow code defines the order of steps that must run. Your activity code does the real work, like calling an API or writing data. A central server stores the state of every single step in a database. Your own worker nodes poll task queues on that server to pick up work. When a worker finishes a step, it sends the result back to the server. If a worker crashes mid-flight, another worker reads the history and picks up the job. You secure this setup by giving workers TLS certificates and namespace roles. Namespace roles decide which workers can poll specific queues and update workflow states.
What native worker roles solve and what they miss
Native namespace roles and TLS checks control who can talk to the central server. They stop random apps from reading your task queues or starting fake workflows. They also keep teams separated by giving each group its own isolated namespace. Still, this setup only decides who logs in to the cluster. It does not inspect what individual database queries or shell commands do in flight. Activity workers still need raw keys to read and write in your production databases. Engineers also log in to live servers to check stuck workflows and fix state bugs. Once a worker or engineer authenticates, the native role allows every query that role supports. If a query returns sensitive fields like emails or card numbers, raw values flow back. Masking rewrites matched fields in results so phone numbers and national IDs stay safe. Native workflow roles alone cannot mask those fields or block a bad delete query.
Steps to harden worker and engineer sessions
Start by giving each worker service a narrow role for its specific task queue. Do not share one admin role across all background workers in your cluster. Next, split your read tasks and write tasks into separate activity pools. Give the read pool a database role that can only run select queries. Keep your workflow event histories clean by not passing secrets in plain text inputs. Store sensitive task data in an external store and pass only a lookup key. Review your server logs often to see who starts, cancels, or terminates running jobs. Finally, limit how engineers run ad-hoc checks against the backing database during an incident.
Process: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What happens when a worker crashes during a temporal process?
The server waits for a timeout and assigns the task to another active worker. The new worker replays the event log and continues from the last saved step.
Should I put database queries inside workflow code or activity code?
Always put database queries and network calls inside your activity code. Workflow code must stay deterministic so it can replay history logs without side effects.
How do I keep sensitive data out of the workflow event history?
Encrypt payloads on the worker before sending them to the central server. You can also mask emails, phone numbers, and card numbers at the data layer.