Restate / Effect Cluster → Temporal: a mapping for onboarding

A reference for engineers who know Restate or Effect Cluster and are ramping up on upstream Temporal. It lives next to the architecture diagrams, which overlay section 4 onto the upstream package graph.

Sources: Temporal server at aaa291ba3, sdk-typescript at 8161cd1c; Restate server at 29f74c1ce (v1.8), sdk-typescript at 2433827; Effect monorepo at f79b23118 (Effect 4.0.0, @stability unstable for workflow/cluster); DeepWiki pages for Temporal and Restate (read 2026-10-05). Paths are relative to each repo root. T/ = temporal server, TS/ = temporal sdk-typescript packages, R/ = restate server, RS/ = restate sdk-typescript packages/libs, E/ = packages/effect/src in the Effect repo.

Contents

1. The thesis
2. Architecture crosswalk
3. The divergences that matter day to day
4. Temporal concerns by code area
5. Quick mapping table
6. Guarantees side by side
7. Reading order in the Temporal repo
8. Relation to fireline / firegrid
9. Caveats about the DeepWiki pages
10. Glossary: Part A, Temporal terms and Part B, internal and other-system terms

1. The thesis

All three are "journal + replay" durable execution engines, but they sit at three different points on two axes:

1. Source of truth. Restate owns a replicated log (Bifrost) and every partition is a deterministic state machine replaying that log into RocksDB. Temporal has no log: a pluggable database is the truth, fenced by a per-shard RangeID compare-and-swap, with side effects written as task rows in the same transaction as state (a transactional outbox). Effect Cluster is also database-as-truth, but at a far thinner layer: two SQL tables (cluster_messages, cluster_replies) hold persisted RPC requests and their replies, and the "journal" is just the set of replies keyed by step name.
2. Dispatch direction. Restate pushes: the partition leader's invoker opens HTTP/2 to your endpoint and streams the journal at it. Temporal pulls: workers long-poll task queues owned by Matching, and the server never dials user code. Effect has no server at all: every runner is both the engine and the user code, and the owner of a shard polls the messages table for work addressed to its entities.
3. Fencing. Restate fences at the log (stale leader epochs are applied then ignored). Temporal fences at the DB (stale RangeID writes fail). Effect Cluster has leases (advisory locks or a cluster_locks row) but no fencing token on writes, so a paused old owner can still write replies; the only guard is UNIQUE(request_id, kind) on replies.

A useful way to hold the three: Effect Cluster is what you get if you keep Temporal's "DB is truth, replay the body" idea but delete history events, Matching, versioning, and fencing, and fold activities into the owner's process. Restate is what you get if you replace the DB with a log and make the server dial you.

2. Architecture crosswalk

3. The divergences that matter day to day

3.1 Log-first vs database-first vs "two tables"

Restate's PartitionProcessor::run_inner is a select! over a Bifrost read stream; every record goes through apply_record → StateMachine::apply → RocksDB txn commit, identically on leaders and followers. Failover is "stop ignoring Actions". Durability is the loglet's write quorum; trimming is gated by replica durable LSNs plus object-store snapshots.

Temporal's equivalent is api/update_workflow_util.go:GetAndUpdateWorkflowWithNew: lock the execution in the host-level cache, mutate MutableState, CloseTransactionAsMutation, then one persistence call carrying RangeID, the mutation, new events, and Tasks map[Category][]Task. Events are appended to history_node before the mutable-state write (T/common/persistence/cassandra/execution_store.go:110); orphans are unreachable until mutable state points at them.

Effect's equivalent is Sharding.sendOutgoing → MessageStorage.saveRequest (returns Success | Duplicate{lastReceivedReply}), and on the handler side saveReply which sets processed and inserts the reply in one transaction. There is no per-execution row at all. Resume is clearReplies on the run message (guarded by last_reply_id = expected, a CAS against concurrent resets) followed by redelivery of the original message, which replays the body.

Tradeoffs:

• Restate: lowest write amplification and total consistency control; must operate a log, Raft, snapshots and trim. Warm followers mean fast failover.
• Temporal: pluggable storage, DB-managed replication, multi-region; a DB round trip per state change and a frozen shard count. New shard owners rebuild mutable-state cache from the DB.
• Effect: zero infrastructure beyond a SQL DB and an embeddable library; but no fencing, replay cost grows without bound (no continue-as-new), and every durable step is at least one row insert plus one poll.

3.2 Push vs pull vs self-hosted

Restate's invoker opens the connection, sends StartMessage + eager state, replays the journal, then streams bidirectionally; SuspensionMessage{awaiting_on} closes the stream. Backpressure is the invoker's per-node concurrency limit and memory pools. Endpoints are passive: Lambda, Cloudflare Workers, tunnels.

Temporal's Matching owns task queues. AddTask tries TrySyncMatch to a parked long-poller and spools to tasks on miss. Sticky queues give each worker a private partition so its V8-cached workflow is reused instead of replayed. Partitions form a tree (default 4) with forwarding; fairness/priority backlogs are in pri_*/fair_*.

Effect has no separation. Workflow entities register with { concurrency: 2, maxIdleTime: 10s }; activities are RPCs to the same entity address, so they run on the owner, under Rpc.wrap({fork: true, uninterruptible: true}). If the owner dies, the next owner's resetShards nulls last_read, the poll redelivers both run and activity, and the activity re-executes with the same attempt number (at-least-once). Read-but-unfinished messages are also reclaimable after a 10-minute last_read window.

Tradeoffs:

• Pull (Temporal): workers behind NAT, natural backpressure, scale by adding pollers; cost is a whole extra service and sticky-cache misses that replay full history.
• Push (Restate): serverless-friendly, server-side admission control (vqueues, DRR, locks); cost is reachable, registered endpoints.
• Self-hosted (Effect): simplest deployment and no cross-process hop for activities; cost is no independent scaling of workflow vs activity capacity, no task-queue routing, and maxResidentEntities 10,000 per runner as the only admission control.

3.3 Programming model and determinism

The deepest difference remains the unit of execution. Restate: the invocation and its own command journal. Temporal: the workflow task, with the server batching events and the worker returning commands, which is what enables buffered events, speculative tasks for Updates, and transient tasks. Effect: the entity RPC; a workflow is literally four persisted RPCs (run, activity, deferred, resume) and the engine is a thin layer that turns replies into a memo table.

3.4 State and keying

Restate has first-class keyed state: Virtual Objects give ctx.get/set K/V per key, exclusive handlers get single-writer semantics (per-key vqueue holding a Lock), and state lives beside the journal in the partition.

Temporal's only state container is the workflow execution; "entity workflows" keyed by workflow ID, driven by signals/updates and bounded by continueAsNew, are the idiom. CHASM (T/chasm/) is the move to make "workflow" one archetype among many on the same shard/routing/atomic-write substrate; standalone activities and the V2 scheduler already run on it.

Effect Cluster is closest to Restate here, but one level down: Entity is the general actor (one RpcServer per resident ID, concurrency 1 by default, entityMaxIdleTime 1 min, EntityReaper), Singleton and ClusterCron are built on it, and Workflow/<tag> is just an entity type whose ID is the execution ID. There is no durable K/V on an entity, so "virtual object state" is either in your own DB or in replies.

3.5 Control plane

Restate's admin role owns the schema registry, cluster controller (placement, leader election, seal/extend, snapshots/trim) and SQL introspection; schema changes are also appended to each partition log as UpsertSchema.

Temporal spreads it across Frontend operator/admin APIs, the Worker service's system workflows, Matching's root partition for versioning user data, one Matching node for the Nexus endpoint registry, and dynamic config.

Effect Cluster has no control plane. Placement is a pure function of the cluster_runners rows; health is one singleton pinging runners (layerPing, layerK8s); there is no admin API, no UI, no namespaces, no rate limits.

4. Temporal concerns by code area

Which Temporal concepts live in which part of the server. One subsection per top-level area of the upstream repository (the same areas as the architecture diagrams), listing the glossary terms that area implements, the specific packages that own them, and links to the Temporal docs and to the glossary entry in section 10. A term can appear under several areas when its implementation spans them. sdk marks concerns implemented in the SDKs rather than the server. Package links are pinned to upstream commit 4db93cd73e.

The same data drives the Temporal concerns panel on the generated architecture pages (pnpm deps:graph, then dist/architecture/index.html): selecting an area or node shows this list filtered to it, with each owner package linked to its diagram node. Source of truth: scripts/concerns.json; regenerate this section with python3 scripts/architecture.py --concerns-markdown.

service/frontend

service/history

service/matching

service/worker

client

common/persistence

common

temporal

api

cmd

sdk

chasm

5. Quick mapping table

One line per concept for fast lookup. Each linked term jumps to its entry in section 10, which has the full definition and source links.

6. Guarantees side by side

7. Reading order in the Temporal repo

Start with docs/architecture/ (history-service.md, workflow-lifecycle.md, chasm.md, nexus.md, workflow-update.md, speculative-workflow-task.md) and service/matching/fairness.md. Then follow a start request:

1. service/frontend/workflow_handler.go → client/history/client.go (shard routing) → service/history/handler.go.
2. service/history/api/startworkflow/, then api/update_workflow_util.go for the generic lock/mutate/persist loop.
3. service/history/workflow/mutable_state_impl.go, workflow_task_state_machine.go, historybuilder/.
4. common/persistence/data_interfaces.go (UpdateWorkflowExecutionRequest), schema/cassandra/temporal/schema.cql.
5. service/history/queues/ (queue_base.go, queue_immediate.go, queue_scheduled.go, scheduler.go), transfer_queue_active_task_executor.go, timer_queue_active_task_executor.go.
6. service/matching/matching_engine.go → task_queue_partition_manager.go → physical_task_queue_manager.go → pri_matcher.go, pri_backlog_manager.go.
7. service/history/shard/context_impl.go (renewRangeLocked, acquireShard), shard/controller_impl.go.
8. chasm/ (tree.go, engine.go, lib/scheduler), then service/history/hsm/.
9. service/history/ndc/ and replication/ only for XDC.

Side-by-side counterparts:

• Restate: crates/worker/src/partition/mod.rs (run_inner), partition/state_machine/mod.rs, partition/leadership/, crates/invoker-impl/src/invocation_task/service_protocol_runner_v4.rs, crates/bifrost/src/bifrost_admin.rs, crates/partition-store/src/keys.rs.
• Effect: E/workflow/Workflow.ts (make, intoResult, withCompensation), E/workflow/WorkflowEngine.ts (interface, layerMemory), E/cluster/ClusterWorkflowEngine.ts (makeWorkflowEntity, resume, activity handler ~474), E/cluster/Sharding.ts (sendOutgoing, assignment loop ~1244), E/cluster/SqlMessageStorage.ts (unprocessedMessages, clearReplies), E/cluster/SqlRunnerStorage.ts, E/cluster/internal/entityManager.ts.

8. Relation to fireline / firegrid

Both of your projects are log-first: one append-only stream is the truth and everything else is a projection replayed from it. That is Restate's shape, not Temporal's or Effect's. In Temporal there is no stream to tail; queue processors read task rows, not events. In Effect there is no stream either; the message table is an outbox that gets polled.

Firegrid's primitive surface against all three:

Firegrid's "model owns control flow, log makes the chosen schedule replayable" is closest to Effect's stance (no determinism checks; whatever replays, replays) and to Restate's (mismatch detected after the fact), and furthest from Temporal's (code must re-derive identical commands). The Effect engine is also the most directly reusable for firegrid's shape: wait_for is exactly a DurableDeferred, and a durable wait_until(prompt) is scheduleClock + a deferred, which is how DurableClock is already built. The thing Effect would not give you that Temporal and Restate do is detection when the model makes a different choice on replay; with Effect, a renamed or reordered step just silently binds to a different reply, which for an LLM-driven schedule means you'd want the step name to be a hash of the model's decision, not an ordinal.

Fireline's conductor/middleware chain has analogues in Temporal's interceptor chains and Restate's tower layers on ingress; Effect's closest match is Rpc.wrap middleware around entity handlers. None of the three put policy middleware around the execution stream itself.

9. Caveats about the DeepWiki pages

Both wikis are LLM-generated and lag migrations. Temporal (indexed 2026-09-23) still cites a removed components/ directory, describes Nexus only via the CHASM path even though HSM is still the default behind nexusoperation.enableChasmWorkflowOperations, and wrongly says workers can report to History directly. Restate's mixes the polling LegacyClusterState with gossip FdState without saying which is authoritative. Prefer in-repo docs/architecture/ for Temporal. There is no DeepWiki read for Effect; the Effect notes above are from source only.

10. Glossary

Every entry explains the concept, links an authoritative source, and then says what the nearest thing is in Restate and in Effect Cluster. Link conventions:

• Temporal: docs.temporal.io pages (the same targets the official glossary links to), or the server repo's docs/architecture/ for internals.
• Restate: docs.restate.dev pages, or the server repo for internals.
• Effect: there are no published docs for the cluster/workflow modules yet, so links are source permalinks at commit f79b23118 under packages/effect/src/ (abbreviated E/). Base: https://github.com/Effect-TS/effect/blob/f79b23118bce44696c044bf7b1141ec55fece216/packages/effect/src/
• "No analogue" means the concept does not exist in that system, not that the underlying need is unmet.

Part A follows the official Temporal glossary (https://docs.temporal.io/glossary). Section 4 maps the same terms onto the owning packages. Part B covers internal and other-system terms used in this document.

Part A: Temporal glossary terms

A.1 Core model

Temporal — A runtime for "reentrant processes": functions whose state and progress survive process and host failure because the server records every step and can replay them on any worker. The platform is the server (four services plus persistence) and the workers you run. https://docs.temporal.io/temporal

• Restate: the equivalent runtime; one Rust binary with roles, plus your service endpoints. https://docs.restate.dev/foundations/key-concepts
• Effect: Effect Cluster, a library inside the effect package; no separate server. E/cluster/index.ts

Durable Execution — The property that a Workflow Execution keeps its state and progress across failures. Implemented by journaling the results of non-deterministic steps and replaying the code against that journal. https://docs.temporal.io/temporal#durable-execution

• Restate: same idea, journal per invocation, replay on every attempt. https://docs.restate.dev/foundations/key-concepts
• Effect: same idea, journal is the set of persisted replies keyed by step name. E/workflow/Workflow.ts

Temporal Platform / Temporal Application — The Platform is a Temporal Service plus Worker Processes. An Application is the set of Workflow Executions your code produces. https://docs.temporal.io/temporal#temporal-platform

• Restate: server plus deployed services; the set of invocations. https://docs.restate.dev/references/architecture
• Effect: runners plus a SQL database; the set of executions. E/cluster/Sharding.ts

Temporal Service (formerly Temporal Cluster) — A Temporal Server paired with a Persistence store (Cassandra, MySQL, Postgres, SQLite) and a Visibility store. "Cluster" is being phased out in favour of "Service". https://docs.temporal.io/temporal-service

• Restate: a Restate cluster: nodes with roles, the replicated log, the metadata store, and optional object store for snapshots. https://docs.restate.dev/server/clusters
• Effect: a SQL database plus any number of runners. E/cluster/SqlMessageStorage.ts

Temporal Server — The four horizontally scalable services (Frontend, History, Matching, Worker) that together implement the server. https://docs.temporal.io/temporal-service/temporal-server

• Restate: one binary with five roles (worker, log-server, metadata-server, admin, http-ingress). https://docs.restate.dev/server/overview
• Effect: no server; every runner is the engine.

Frontend Service — The stateless gRPC (and HTTP) gateway. It authenticates, rate-limits, validates the Namespace, and routes each call to the right History shard or Matching partition. All SDK traffic goes through it. https://docs.temporal.io/temporal-service/temporal-server#frontend-service

• Restate: the HTTP ingress role (port 8080) for invocations and the admin role (port 9070) for control-plane calls. https://docs.restate.dev/services/invocation/http
• Effect: WorkflowProxy / EntityProxy HTTP or RPC groups served by any runner. E/workflow/WorkflowProxy.ts

History Service — The stateful core. It owns Workflow Execution state (mutable state and Event History), decides what to do next, and runs the internal task queues (transfer, timer, visibility, outbound, replication). Scaled by History Shards. https://docs.temporal.io/temporal-service/temporal-server#history-service

• Restate: the worker role, i.e. partition processors applying the log into RocksDB. https://docs.restate.dev/references/architecture
• Effect: the shard-owning runner's entity manager plus the cluster workflow engine. E/cluster/ClusterWorkflowEngine.ts

History Shard — A fixed-count partition of the execution space. Each shard is owned by exactly one History host at a time and is the unit of throughput scaling. Shard count cannot be changed after the cluster is created. https://docs.temporal.io/temporal-service/temporal-server#history-shard

• Restate: a partition (default 24), a key range of the 64-bit partition key space, owned by a leader replica. https://docs.restate.dev/server/clusters
• Effect: a shard (300 per shard group), a hash bucket of entity IDs, owned by a runner holding its lease. E/cluster/ShardingConfig.ts

Matching Service — Hosts Task Queues. It matches tasks produced by History to Worker long-polls, either in memory (sync match) or via a persisted backlog. https://docs.temporal.io/temporal-service/temporal-server#matching-service

• Restate: no analogue; the server pushes to the endpoint.
• Effect: no analogue; messages are addressed directly to the owning runner.

Worker Service — The server-side service that runs system Workflows (scanner, batch operations, schedules V1, worker deployments, migrations) and other background jobs using the Go SDK against the Frontend. https://docs.temporal.io/temporal-service/temporal-server#worker-service

• Restate: admin role plus leader-side background tasks (cleaner, log trimmer, durability tracker). https://docs.restate.dev/server/overview
• Effect: no analogue beyond the runner-health singleton. E/cluster/RunnerHealth.ts

Namespace — The unit of isolation. Workflow IDs, Task Queues, retention, search attributes, and replication settings are scoped per Namespace. https://docs.temporal.io/namespaces

• Restate: no analogue within one cluster; isolation is per cluster.
• Effect: no analogue; shard groups are only a placement knob. E/cluster/ClusterSchema.ts

Temporal Service configuration — The YAML config for a self-hosted server (persistence, services, membership, TLS, archival), separate from dynamic config. https://docs.temporal.io/temporal-service/configuration

• Restate: restate.toml, hot-reloadable. https://docs.restate.dev/references/server-config
• Effect: ShardingConfig layer values. E/cluster/ShardingConfig.ts

A.2 Workflows

Workflow — Day-to-day shorthand for Workflow Type, Workflow Definition, or Workflow Execution. https://docs.temporal.io/workflows

• Restate: a handler on a Service, Virtual Object, or Workflow, depending on whether it is keyed and single-run. https://docs.restate.dev/foundations/services
• Effect: a Workflow.make(...) definition or one of its executions. E/workflow/Workflow.ts

Workflow Definition — The user code that defines a Workflow. It must be deterministic: on replay it must issue the same Commands in the same order. Non-deterministic work goes in Activities. https://docs.temporal.io/workflow-definition

• Restate: the handler function. Determinism is not required by the SDK; a divergence on replay is detected as a journal mismatch. https://docs.restate.dev/develop/ts/services
• Effect: the handler passed to Workflow.toLayer. Determinism is neither required nor detected. E/workflow/Workflow.ts

Workflow Type — The name that maps to a Workflow Definition, used when starting executions and registering workers. https://docs.temporal.io/workflow-definition#workflow-type

• Restate: the service/handler pair in the schema registry. https://docs.restate.dev/foundations/handlers
• Effect: the tag string; the entity type becomes Workflow/<tag>. E/cluster/ClusterWorkflowEngine.ts

Workflow Execution — One durable run of a Workflow Definition, identified by Workflow ID plus Run ID. It is the main unit of execution: it has an Event History, can be signalled, queried, updated, and can spawn Activities and children. https://docs.temporal.io/workflow-execution

• Restate: an invocation, identified by an InvocationId. https://docs.restate.dev/foundations/invocations
• Effect: an execution, identified by a 32-hex execution ID. E/workflow/Workflow.ts

Workflow ID — A user-chosen, application-level identifier. Within a Namespace, at most one execution with that ID can be open at a time, which is how Temporal provides entity-style uniqueness. https://docs.temporal.io/workflow-execution/workflowid-runid#workflow-id

• Restate: the Virtual Object key or Workflow key. Plain Services are unkeyed. https://docs.restate.dev/foundations/services
• Effect: the execution ID, derived from idempotencyKey(payload). E/workflow/Workflow.ts

Run ID — A platform-generated, globally unique ID for one run of a Workflow ID. Continue-As-New, retries, cron, and reset all produce new Run IDs under the same Workflow ID. https://docs.temporal.io/workflow-execution/workflowid-runid#run-id

• Restate: no separate ID; InvocationId identifies the one attempt chain. https://docs.restate.dev/foundations/invocations
• Effect: no analogue; one execution ID is one run forever.

Workflow ID Reuse Policy — Controls whether a new execution may reuse a Workflow ID that belongs to a closed execution (allow, allow only if the previous failed, reject). https://docs.temporal.io/workflow-execution/workflowid-runid#workflow-id-reuse-policy

• Restate: a repeat request with the same idempotency key returns the stored result until journal retention expires; no per-start policy. https://docs.restate.dev/services/invocation/http
• Effect: no analogue; the same payload always maps to the same execution.

Workflow ID Conflict Policy — Controls what happens when starting a Workflow ID that is currently running: fail, return the existing run, or terminate the existing run and start fresh. https://docs.temporal.io/workflow-execution/workflowid-runid#workflow-id-conflict-policy

• Restate: a duplicate idempotent request attaches to the running invocation; exclusive Virtual Object handlers queue behind each other. https://docs.restate.dev/services/invocation/http
• Effect: execute on a running execution attaches and polls for its result. E/workflow/WorkflowEngine.ts

Continue-As-New — Closes the current run and atomically starts a new run of the same Workflow ID with a fresh Event History and the state you pass along. Used to bound history size for long-lived workflows. https://docs.temporal.io/workflow-execution/continue-as-new

• Restate: not needed; the journal is per invocation and is trimmed on completion. Long-lived state belongs in Virtual Object K/V. https://docs.restate.dev/develop/ts/state
• Effect: no analogue; replay cost grows with step count.

Child Workflow — A Workflow Execution started from inside another. The parent gets the child's result as an Event and can control what happens to the child when the parent closes. https://docs.temporal.io/child-workflows

• Restate: a Call to another service or workflow from a handler, awaited as a durable promise. https://docs.restate.dev/develop/ts/service-communication
• Effect: execute with a parent reference; the child sends resume to the parent on completion. E/cluster/ClusterWorkflowEngine.ts

Parent Close Policy — What happens to a child when its parent closes: terminate, request cancel, or abandon. https://docs.temporal.io/parent-close-policy

• Restate: no analogue; called invocations are independent unless explicitly cancelled. https://docs.restate.dev/services/invocation/managing-invocations
• Effect: children are only affected through the parent's finalizers. E/workflow/Workflow.ts

Delay Workflow Execution — A start option that delays the first Workflow Task by a duration. https://docs.temporal.io/workflow-execution/timers-delays

• Restate: ?delay= on ingress or a delayed send. https://docs.restate.dev/services/invocation/http
• Effect: DeliverAt on the persisted message. E/cluster/DeliverAt.ts

Temporal Cron Job — A legacy way to run a Workflow on a cron spec by chaining runs under one Workflow ID. Schedules supersede it. https://docs.temporal.io/cron-job

• Restate: no built-in cron; implemented with delayed self-sends. https://docs.restate.dev/guides/cron
• Effect: ClusterCron. E/cluster/ClusterCron.ts

Schedule — A first-class server resource that starts Workflow Executions on a calendar or interval spec, with pause, backfill, overlap policies, and jitter. https://docs.temporal.io/schedule

• Restate: no analogue beyond the cron guide pattern. https://docs.restate.dev/guides/cron
• Effect: ClusterCron (no backfill or overlap policy). E/cluster/ClusterCron.ts

Reset — Terminates an execution and starts a new run from a chosen point in its Event History, discarding later progress. https://docs.temporal.io/workflow-execution/event#reset

• Restate: restart-as-new restarts a completed or killed invocation from scratch, not from a point. https://docs.restate.dev/services/invocation/managing-invocations
• Effect: resume after SuspendOnFailure replays from scratch reusing cached replies. E/workflow/Workflow.ts

State Transition — One unit of progress of a Workflow Execution, as counted by the server (used for Cloud billing and the transition count clock). https://docs.temporal.io/workflow-execution#state-transition

• Restate: an applied log record (LSN) at the partition level. https://docs.restate.dev/references/architecture
• Effect: a persisted request/reply pair.

Retention Period — How long a closed execution's Event History stays in persistence before deletion (default 72 hours on self-hosted). https://docs.temporal.io/temporal-service/temporal-server#retention-period

• Restate: journal-retention per service. https://docs.restate.dev/services/configuration
• Effect: no analogue; rows persist until deleted.

Archival — A self-hosted feature that copies closed Event Histories and visibility records to blob storage after retention expires. https://docs.temporal.io/temporal-service/archival

• Restate: partition snapshots to object store serve recovery, not audit. https://docs.restate.dev/server/snapshots
• Effect: no analogue.

Workflow History Export — Temporal Cloud feature exporting closed histories to a customer storage sink. https://docs.temporal.io/cloud/export

• Restate / Effect: no analogue.

Memo — Non-indexed, user-supplied metadata attached to an execution and returned by describe and list. https://docs.temporal.io/workflow-execution#memo

• Restate: invocation headers. https://docs.restate.dev/services/invocation/http
• Effect: fields in the payload.

Workflow cache — The worker-side in-memory cache of Workflow Executions that lets Sticky Execution skip replay. https://docs.temporal.io/workflow-execution#workflow-cache

• Restate: no SDK-side cache; the server pushes the journal each attempt.
• Effect: the resident WorkflowInstance per entity. E/workflow/WorkflowEngine.ts

A.3 Events, commands, tasks

Event — A record the server writes into Event History, either from an external occurrence (a Signal arrived, a timer fired) or from a Command the workflow issued. https://docs.temporal.io/workflow-execution/event#event

• Restate: a journal notification (completion) entry, plus the partition log record. https://github.com/restatedev/restate/blob/main/service-protocol/dev/restate/service/protocol.proto
• Effect: a reply row. E/cluster/Reply.ts

Event History — The append-only log of Events for one execution. It is the full state of the execution and is what workers replay. https://docs.temporal.io/workflow-execution/event#event-history

• Restate: the invocation journal (JournalV2), deleted after retention. https://docs.restate.dev/foundations/invocations
• Effect: the set of replies for an execution; not ordered as a history. E/cluster/MessageStorage.ts

Command — A requested action a worker returns after a Workflow Task: schedule an Activity, start a timer, signal another workflow, complete the workflow. The server validates it and writes Events. https://docs.temporal.io/workflow-execution#command

• Restate: a journal command entry sent by the SDK (Call, Sleep, Run, SetState...). Same word, same meaning. https://github.com/restatedev/restate/blob/main/service-protocol/dev/restate/service/protocol.proto
• Effect: an entity RPC sent by the running body. E/cluster/ClusterWorkflowEngine.ts

Task — The context a worker needs to make progress on one execution: either a Workflow Task or an Activity Task. https://docs.temporal.io/tasks#task

• Restate: the invoker's decision to (re)invoke, delivered as an HTTP request. https://docs.restate.dev/references/architecture
• Effect: a persisted message row. E/cluster/Message.ts

Workflow Task — A Task telling a worker to advance a Workflow Execution. It carries the Event History (or the delta since the sticky cache) and expects Commands back. https://docs.temporal.io/tasks#workflow-task

• Restate: the invocation stream (StartMessage, replayed journal, live notifications). https://docs.restate.dev/references/architecture
• Effect: a (re)delivered run message. E/cluster/ClusterWorkflowEngine.ts

Workflow Task Execution — A worker picking up a Workflow Task, replaying history in the sandbox, running the code until it blocks, and responding with Commands. https://docs.temporal.io/tasks#workflow-task-execution

• Restate: one attempt of an invocation against the endpoint. https://docs.restate.dev/foundations/invocations
• Effect: one run of the workflow body.

Workflow Task Timeout — The maximum time the server waits for a worker to start processing a Workflow Task before rescheduling it (default 10 seconds). https://docs.temporal.io/encyclopedia/detecting-workflow-failures#workflow-task-timeout

• Restate: inactivity-timeout and abort-timeout on the invocation stream. https://docs.restate.dev/services/configuration
• Effect: the 10-minute last_read reclaim window. E/cluster/SqlMessageStorage.ts

Activity Task — A Task carrying the input and context for one Activity attempt. https://docs.temporal.io/tasks#activity-task

• Restate: the ExecuteRun instruction from the SDK core. https://docs.restate.dev/develop/ts/durable-steps
• Effect: a persisted activity{name, attempt} request. E/cluster/ClusterWorkflowEngine.ts

Activity Task Execution — One attempt of running an Activity Definition with the Activity Task's context. https://docs.temporal.io/tasks#activity-task-execution

• Restate: one execution of a ctx.run closure.
• Effect: one run of an Activity's execute. E/workflow/Activity.ts

Task Token — An opaque identifier for one Activity Task Execution, used to complete it asynchronously or send heartbeats from outside the worker. https://docs.temporal.io/activity-execution#task-token

• Restate: the awakeable ID. https://docs.restate.dev/develop/ts/external-events
• Effect: the DurableDeferred token. E/workflow/DurableDeferred.ts

Side Effect — A way to run a short non-deterministic snippet inside workflow code and record its result as an Event so replay reuses it. No retries, no separate task. https://docs.temporal.io/workflow-execution/event#side-effect

• Restate: ctx.run without retry; ctx.rand and ctx.date for the common cases. https://docs.restate.dev/develop/ts/durable-steps
• Effect: an Activity with no retry. E/workflow/Activity.ts

A.4 Activities

Activity — Shorthand for Activity Type, Definition, or Execution: the unit of non-deterministic, retryable work. https://docs.temporal.io/activities

• Restate: ctx.run (in-process) or a call to another service (out-of-process). https://docs.restate.dev/develop/ts/durable-steps
• Effect: Activity.make. E/workflow/Activity.ts

Activity Definition — The function that implements an Activity. It may do anything: I/O, randomness, long blocking calls. The server retries it per Retry Policy. https://docs.temporal.io/activity-definition

• Restate: the closure passed to ctx.run.
• Effect: the execute Effect.

Activity Type — The name mapping to an Activity Definition. https://docs.temporal.io/activity-definition#activity-type

• Restate: the optional ctx.run(name, ...) label.
• Effect: the Activity name, part of the dedup key.

Activity Execution — The full chain of attempts for one scheduled Activity, from schedule to final result. https://docs.temporal.io/activity-execution

• Restate: all attempts of one Run journal entry.
• Effect: all attempts of one Activity name.

Activity ID — The unique ID of an Activity Execution within its workflow. https://docs.temporal.io/activity-execution#activity-id

• Restate: the journal entry index.
• Effect: name plus attempt.

Workflow Activity — An Activity orchestrated by a Workflow, as opposed to a Standalone Activity. https://docs.temporal.io/workflow-activity

• Restate: any ctx.run or Call inside a handler.
• Effect: any Activity inside a workflow body.

Standalone Activity — An Activity started directly from a client with no enclosing workflow, backed by CHASM. https://docs.temporal.io/standalone-activity

• Restate: a plain Service handler invoked via ingress. https://docs.restate.dev/foundations/services
• Effect: an entity RPC outside any workflow. E/cluster/Entity.ts

Local Activity — An Activity executed inside the worker's workflow task, skipping the Task Queue round trip. Cheaper but bounded by the Workflow Task Timeout. https://docs.temporal.io/local-activity

• Restate: ctx.run exactly. https://docs.restate.dev/develop/ts/durable-steps
• Effect: every Activity (there is no remote kind).

Asynchronous Activity Completion — An Activity returns "will complete later" and an external system completes it by Task Token. https://docs.temporal.io/activity-execution#asynchronous-activity-completion

• Restate: awakeables. https://docs.restate.dev/develop/ts/external-events
• Effect: DurableDeferred. E/workflow/DurableDeferred.ts

Activity Heartbeat — A periodic ping from the worker running an Activity, carrying optional progress details, so the server can detect a dead worker and the Activity can resume from the last heartbeat. https://docs.temporal.io/encyclopedia/detecting-activity-failures#activity-heartbeat

• Restate: no analogue; the invoker holds the open stream and detects disconnect.
• Effect: no analogue.

Heartbeat Timeout — Max time between heartbeats before the server fails the attempt. https://docs.temporal.io/encyclopedia/detecting-activity-failures#heartbeat-timeout

• Restate: inactivity-timeout (suspend an idle invocation) and abort-timeout. https://docs.restate.dev/services/configuration
• Effect: no analogue.

Schedule-To-Start Timeout — Max time an Activity Task may wait in a Task Queue before a worker picks it up. Usually left unset. https://docs.temporal.io/encyclopedia/detecting-activity-failures#schedule-to-start-timeout

• Restate / Effect: no analogue (no queue between engine and code).

Start-To-Close Timeout — Max duration of one Activity attempt. Required unless Schedule-To-Close is set. https://docs.temporal.io/encyclopedia/detecting-activity-failures#start-to-close-timeout

• Restate: RestatePromise.orTimeout or the service abort-timeout. https://docs.restate.dev/develop/ts/durable-timers
• Effect: Effect.timeout around execute.

Schedule-To-Close Timeout — Max duration for the whole Activity Execution including retries. https://docs.temporal.io/encyclopedia/detecting-activity-failures#schedule-to-close-timeout

• Restate: retry policy max-duration. https://docs.restate.dev/services/configuration
• Effect: a total-duration bound in the Activity.retry schedule.

Retry Policy — Server-side retry attributes: initial interval, backoff coefficient, max interval, max attempts, non-retryable error types. Applied to Activities by default and to Workflows if set. https://docs.temporal.io/encyclopedia/retry-policies

• Restate: per-service retry policy (initial interval, exponentiation factor, max attempts, max interval, pause-or-kill on exhaustion) plus RunOptions for ctx.run. https://docs.restate.dev/services/configuration
• Effect: Activity.retry (opt-in) and interruptRetryPolicy (on by default). E/workflow/Activity.ts

Idempotency — Designing Activities so repeating them has the same effect as running once, which is required because delivery is at-least-once. https://docs.temporal.io/activity-definition#idempotency

• Restate: same requirement for ctx.run; idempotency keys and awakeable IDs help. https://docs.restate.dev/guides/durable-webhooks
• Effect: Activity.idempotencyKey supplies a stable key; WithTransaction gives exactly-once for same-DB effects. E/workflow/Activity.ts

A.5 Messages into a running execution

Signal — An asynchronous, fire-and-forget message to a running execution. It is written as an Event and triggers a Workflow Task; the workflow handles it with a registered handler. https://docs.temporal.io/sending-messages#sending-signals

• Restate: a shared handler on a Virtual Object or Workflow, or resolving an awakeable or durable promise. https://docs.restate.dev/develop/ts/external-events
• Effect: completing a DurableDeferred by token. E/workflow/DurableDeferred.ts

Signal-With-Start — Atomically start the execution if absent, then deliver a Signal. https://docs.temporal.io/sending-messages#signal-with-start

• Restate: calling a Virtual Object creates it implicitly; for Workflows, submit run then call a shared handler. https://docs.restate.dev/foundations/services
• Effect: execute plus a deferred completion, with no atomicity across the two.

Query — A synchronous, read-only request answered by a worker from its cached workflow state. It writes no Events and cannot change state. https://docs.temporal.io/sending-messages#sending-queries

• Restate: a shared handler that reads state or peeks a durable promise. https://docs.restate.dev/develop/ts/state
• Effect: no analogue; poll returns only the final result.

Update — A synchronous request-and-response to a running execution that may mutate state. It has validation, accepted, and completed phases, and the caller can wait for either. https://docs.temporal.io/sending-messages#sending-updates

• Restate: a shared handler that writes state. https://docs.restate.dev/foundations/handlers
• Effect: no analogue.

Dynamic Handler — A catch-all Workflow, Activity, Signal, or Query handler invoked when no registered name matches. https://docs.temporal.io/dynamic-handler

• Restate / Effect: no analogue.

Timer — Durable, deterministic time APIs inside workflow code (sleep, timeouts on condition). The server fires them even if no worker is running. https://docs.temporal.io/workflow-execution/timers-delays

• Restate: ctx.sleep, orTimeout. https://docs.restate.dev/develop/ts/durable-timers
• Effect: DurableClock.sleep. E/workflow/DurableClock.ts

Workflow Execution Timeout — Max total time for a Workflow ID across all runs, including retries and Continue-As-New. https://docs.temporal.io/encyclopedia/detecting-workflow-failures#workflow-execution-timeout

• Restate / Effect: no analogue.

Workflow Run Timeout — Max time for one run. https://docs.temporal.io/encyclopedia/detecting-workflow-failures#workflow-run-timeout

• Restate: abort-timeout fails the attempt, not the invocation. https://docs.restate.dev/services/configuration
• Effect: no analogue.

A.6 Workers and dispatch

Worker — Shorthand for Worker Program or Worker Process: the thing that runs your code. https://docs.temporal.io/workers#worker

• Restate: a service endpoint (your HTTP server or Lambda). https://docs.restate.dev/develop/ts/serving
• Effect: a runner. E/cluster/Runner.ts

Worker Process — A long-running process that polls Task Queues, executes workflow and activity code, and reports results. https://docs.temporal.io/workers#worker-process

• Restate: a passive endpoint the server invokes. https://docs.restate.dev/develop/ts/serving
• Effect: a runner process that owns shards and polls the message table. E/cluster/Sharding.ts

Worker Entity — One worker within a process, bound to one Task Queue and one Namespace. https://docs.temporal.io/workers#worker-entity

• Restate: one service registered on an endpoint.
• Effect: one Entity registration in a runner. E/cluster/Entity.ts

Worker Program — The static code that defines the Worker Process (which workflows and activities it hosts). https://docs.temporal.io/workers#worker-program

• Restate: restate.endpoint().bind(...).
• Effect: the Layer built from Workflow.toLayer and entity layers.

Task Queue — A lightweight, dynamically created FIFO queue that workers poll. It is the routing key between server and workers; workflows and activities name one at schedule time. https://docs.temporal.io/task-queue

• Restate: no analogue; routing is by deployment URL in the schema registry. https://docs.restate.dev/services/versioning
• Effect: no analogue.

Task Routing — Using distinct Task Queues to send specific Activities to specific workers (for example, host-specific or GPU-bearing). https://docs.temporal.io/task-routing

• Restate: deployment selection per service. https://docs.restate.dev/services/versioning
• Effect: ShardGroup annotation restricts which runners can own an entity. E/cluster/ClusterSchema.ts

Worker Session — A Go SDK feature to run a sequence of Activities on the same worker without hand-naming a Task Queue. https://docs.temporal.io/task-routing#worker-session

• Restate: not needed; a key pins work to one partition. https://docs.restate.dev/foundations/services
• Effect: activities always run on the owner runner.

Sticky Execution — After a worker processes a Workflow Task, the server routes subsequent tasks for that execution to a worker-specific Task Queue so the cached state is reused instead of replaying from scratch. https://docs.temporal.io/sticky-execution

• Restate: the invoker keeps the HTTP/2 stream open while active; suspension ends it. https://docs.restate.dev/references/architecture
• Effect: the entity stays resident until maxIdleTime. E/cluster/ClusterWorkflowEngine.ts

A.7 Nexus

Nexus RPC — An open protocol for arbitrary-duration operations with both synchronous and asynchronous completion, designed so durable executions can call across service and namespace boundaries. https://github.com/nexus-rpc/api/blob/main/SPEC.md

• Restate: the service protocol plus the ingress API (invocation IDs, attach, output). https://github.com/restatedev/restate/blob/main/service-protocol/dev/restate/service/protocol.proto
• Effect: Effect RPC over HTTP, WebSocket, or socket. E/cluster/Runners.ts

Nexus Service — A named collection of Nexus Operations forming a service contract. https://docs.temporal.io/nexus/services

• Restate: a Service in the schema registry. https://docs.restate.dev/foundations/services
• Effect: an RpcGroup or an Entity type.

Nexus Operation — One operation in a Nexus Service; may complete synchronously or return an operation token and complete later via callback. https://docs.temporal.io/nexus/operations

• Restate: any handler invocation (always async-capable through its invocation ID). https://docs.restate.dev/foundations/invocations
• Effect: an entity RPC or a workflow.

Nexus Operation Handler — Handler code in a worker implementing an Operation. https://docs.temporal.io/nexus/operations

• Restate: a handler function.
• Effect: an RPC handler.

Temporal Operation Handler — A handler kind that backs an Operation with a Workflow, Update, or Activity, giving durable execution on the handler side. https://docs.temporal.io/nexus/temporal-operation-handler

• Restate: a handler that calls a workflow via ctx.workflowClient. https://docs.restate.dev/develop/ts/service-communication
• Effect: WorkflowProxyServer.layerRpcHandlers. E/workflow/WorkflowProxyServer.ts

Nexus Standalone Activity — An Operation backed by a Standalone Activity that completes when the activity returns. https://docs.temporal.io/nexus/standalone-activity

• Restate: a plain Service handler.
• Effect: an entity RPC.

Nexus Endpoint — A named reverse proxy that routes a Nexus Service to a target Namespace and Task Queue (or an external URL). Callers reference endpoints, not workers. https://docs.temporal.io/nexus/endpoints

• Restate: a deployment (endpoint URL or Lambda ARN) in the schema registry. https://docs.restate.dev/services/versioning
• Effect: a runner address in cluster_runners. E/cluster/RunnerAddress.ts

Nexus Registry — The cluster-wide store of Endpoints, owned by one Matching node and polled by others. https://docs.temporal.io/nexus/registry

• Restate: the schema registry in the metadata store. https://docs.restate.dev/server/metadata
• Effect: the cluster_runners table. E/cluster/SqlRunnerStorage.ts

Nexus Machinery — The built-in at-least-once delivery of Operation start, cancel, and completion across Namespace boundaries (outbound queue, callbacks, retries). https://docs.temporal.io/nexus

• Restate: invoker plus outbox and shuffle. https://docs.restate.dev/references/architecture
• Effect: persisted messages plus the storage poll.

Nexus Async Completion Callback — The HTTP callback a handler invokes when an async Operation finishes; the server routes it to the caller's History. https://docs.temporal.io/nexus/operations

• Restate: the invocation's response sink, or awakeable resolution for external systems. https://docs.restate.dev/develop/ts/external-events
• Effect: DurableDeferred token completion.

Nexus Operation Events — Events in the caller's history recording Operation lifecycle (scheduled, started, completed, failed, cancelled, timed out). https://docs.temporal.io/nexus/execution-debugging

• Restate: the Call command and its completion notifications in the journal.
• Effect: the activity request and its reply.

Nexus Service Contract — The shared code package, schema, or docs that let a caller use a Service. https://docs.temporal.io/nexus/services

• Restate: the exported service definition type consumed by serviceClient. https://docs.restate.dev/develop/ts/service-communication
• Effect: shared RpcGroup / Schema definitions.

NexGen — A code generator producing typed Nexus clients from a schema file. https://docs.temporal.io/nexus/nexgen

• Restate / Effect: no analogue (types flow through TypeScript or Schema).

A.8 Data conversion and failures

Payload — The wire representation of a value: bytes plus metadata (encoding, type). All inputs and outputs are Payloads. https://docs.temporal.io/dataconversion#payload

• Restate: raw bytes with a content type in journal entries. https://docs.restate.dev/develop/ts/serialization
• Effect: encoded bytes in the message or reply payload column.

Payload Converter — Serializes a value to a Payload and back (JSON, protobuf, binary). https://docs.temporal.io/payload-converter

• Restate: Serde<T>. https://docs.restate.dev/develop/ts/serialization
• Effect: Schema. https://github.com/Effect-TS/effect/blob/f79b23118bce44696c044bf7b1141ec55fece216/packages/effect/SCHEMA.md

Payload Codec — Transforms Payloads to Payloads after serialization, typically for encryption or compression. Runs outside the workflow sandbox. https://docs.temporal.io/payload-codec

• Restate: JournalValueCodec (experimental). https://docs.restate.dev/develop/ts/serialization
• Effect: no analogue; wrap the Schema.

Data Converter — The bundle of Payload Converters, Payload Codecs, and Failure Converter an SDK uses. https://docs.temporal.io/dataconversion

• Restate: Serde plus codec.
• Effect: Schema per RPC.

Default Data Converter / Custom Data Converter — The built-in chain (null, binary, protobuf JSON, protobuf binary, JSON) versus a user-supplied replacement. https://docs.temporal.io/default-custom-data-converters

• Restate: serde.json default; custom Serde.
• Effect: Schema is always explicit.

Codec Server / Remote data encoding — An HTTP server exposing your Payload Codec so the Web UI and CLI can decode encrypted payloads. https://docs.temporal.io/codec-server

• Restate / Effect: no analogue.

Failure — Temporal's typed error model carried in Events and across SDKs: ApplicationFailure, CancelledFailure, TimeoutFailure, TerminatedFailure, ServerFailure, ActivityFailure, ChildWorkflowFailure, NexusOperationFailure. https://docs.temporal.io/references/failures

• Restate: TerminalError versus retryable errors, with a Failure{code, message, metadata} wire type. https://docs.restate.dev/develop/ts/error-handling
• Effect: Effect Cause persisted through Workflow.Result schemas, plus typed error channels. E/workflow/Workflow.ts

Failure Converter — Converts language error objects to proto Failures and back. https://docs.temporal.io/failure-converter

• Restate: asTerminalError hook. https://docs.restate.dev/develop/ts/error-handling
• Effect: Schema for Cause.

A.9 Visibility and observability

Visibility — The subsystem and APIs for listing, counting, and searching executions. Written asynchronously to Elasticsearch or SQL, so it is eventually consistent. https://docs.temporal.io/temporal-service/visibility

• Restate: SQL introspection over live partition state. https://docs.restate.dev/services/introspection
• Effect: raw SQL on the cluster tables.

List Filter — The SQL-like query string accepted by list and count APIs. https://docs.temporal.io/list-filter

• Restate: SQL. https://docs.restate.dev/references/sql-introspection
• Effect: SQL.

Search Attribute — An indexed key usable in List Filters, set at start or upserted from workflow code. https://docs.temporal.io/search-attribute

• Restate: columns of the sys_* tables; no custom indexed attributes. https://docs.restate.dev/references/sql-introspection
• Effect: no analogue.

Dual Visibility — Running a secondary Visibility store during a migration. https://docs.temporal.io/dual-visibility

• Restate / Effect: no analogue.

Tag — A key-value label on an emitted metric. https://docs.temporal.io/references/sdk-metrics

• Restate: Prometheus labels. https://docs.restate.dev/server/monitoring/metrics
• Effect: Metric tags. E/cluster/ClusterMetrics.ts

Temporal Web UI — The UI for inspecting executions, histories, task queues, and schedules. https://docs.temporal.io/web-ui

• Restate: the UI served by the admin role. https://docs.restate.dev/services/introspection
• Effect: no analogue.

Temporal CLI / tctl — The temporal command-line tool; tctl is its deprecated predecessor. https://docs.temporal.io/cli

• Restate: restate CLI and restatectl. https://docs.restate.dev/references/cli-config
• Effect: no analogue.

A.10 SDKs and clients

Temporal SDK — A language library providing the Client and the Worker, including the deterministic workflow runtime. https://docs.temporal.io/encyclopedia/architecture/temporal-sdks

• Restate: @restatedev/restate-sdk and siblings. https://docs.restate.dev/develop/ts/services
• Effect: the effect package's workflow and cluster modules.

Core SDK — The shared Rust library (sdk-core) implementing polling, state machines, and replay for the TypeScript, Python, .NET, and Ruby SDKs via FFI. https://temporal.io/blog/why-rust-powers-core-sdk

• Restate: restate-sdk-shared-core, Rust compiled to WASM for the TS SDK. https://github.com/restatedev/sdk-shared-core
• Effect: no analogue (pure TypeScript).

Temporal Client — The SDK API to start, signal, query, update, describe, and list executions. https://docs.temporal.io/encyclopedia/temporal-client

• Restate: the ingress client package. https://docs.restate.dev/services/invocation/clients/typescript-sdk
• Effect: Workflow.execute and WorkflowProxy clients. E/workflow/WorkflowProxy.ts

A.11 Replication and high availability

Multi-Cluster Replication — Self-hosted asynchronous replication of executions from an active cluster to passive ones, with namespace-level failover. https://docs.temporal.io/self-hosted-guide/multi-cluster-replication

• Restate / Effect: no analogue; durability is within one cluster.

Global Namespace — A Namespace configured to replicate to a standby cluster. https://docs.temporal.io/global-namespace

• Restate / Effect: no analogue.

Failover / Failback — Switching a Namespace's active cluster or region to the standby and back. https://docs.temporal.io/cloud/high-availability

• Restate: partition leader failover within a cluster. https://docs.restate.dev/server/clusters
• Effect: shard reassignment when a lease expires. E/cluster/Sharding.ts

Replication Lag — The delay between active and standby regions. https://docs.temporal.io/cloud/metrics/openmetrics/metrics-reference#temporal_cloud_v1_replication_lag_p99

• Restate / Effect: no analogue.

High Availability / High Availability features / Multi-region, Multi-cloud, Same-region Replication — Cloud offerings that replicate a Namespace to a second region, cloud, or cell for failover. https://docs.temporal.io/cloud/high-availability

• Restate: the replicated loglet and Raft metadata quorum give in-cluster HA. https://docs.restate.dev/server/clusters
• Effect: database HA plus runner redundancy.

Availability Zone — Placement unit for Cloud HA. https://docs.temporal.io/cloud/high-availability

• Restate: node location in nodes config used for nodeset selection. https://docs.restate.dev/server/clusters
• Effect: no analogue.

A.12 Security and limits

Authorizer Plugin / Claim Mapper — Self-hosted server plugins: the Claim Mapper extracts claims from a JWT, the Authorizer decides per API call. https://docs.temporal.io/self-hosted-guide/security

• Restate: request identity verification for server-to-service calls; ingress auth is external. https://docs.restate.dev/services/security
• Effect: no analogue; handle in the HTTP layer.

Audit Logging — Cloud feature recording forensic access information. https://docs.temporal.io/cloud/audit-logs

• Restate / Effect: no analogue.

Requests Per Second (RPS) — Service-level rate limits configured via dynamic config. https://docs.temporal.io/references/dynamic-configuration#service-level-rps-limits

• Restate: ingress concurrency limit and invoker concurrency limit. https://docs.restate.dev/guides/rate-limiting
• Effect: maxResidentEntities and mailbox capacity. E/cluster/ShardingConfig.ts

Action / Actions Per Second (APS) — Cloud's billing unit (roughly one per state transition that creates work) and its per-namespace rate limit. https://docs.temporal.io/cloud/pricing#action

• Restate / Effect: no analogue.

A.13 Temporal Cloud and release stages

Temporal Cloud; Account ID; Namespace ID; Namespace Name; gRPC Endpoint — The managed offering and its identifiers and per-namespace connection address. https://docs.temporal.io/cloud/namespaces

• Restate: Restate Cloud environments and tunnel. https://docs.restate.dev/cloud/getting-started
• Effect: no analogue.

General Availability / Public Preview / Pre-release — Product release stages. https://docs.temporal.io/evaluate/product-release-stages

• Restate: feature flags in server config. https://docs.restate.dev/references/server-config
• Effect: @stability unstable annotations in source.

Part B: internal and other-system terms used in this document

B.1 Temporal server internals

Mutable state — The materialized record of one execution (execution info, pending activities, timers, children, signals, versioning info), stored in the executions row and cached on the owning History host. Events are the log; mutable state is the fold over it. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md

• Restate: the invocation status, journal, and state tables in the partition store. https://docs.restate.dev/references/architecture
• Effect: none; the WorkflowInstance is rebuilt by replay. E/workflow/WorkflowEngine.ts

RangeID — A monotonically increasing integer on each shard row. A History host claims a shard by compare-and-swapping it, and every write for that shard carries it; a mismatch means another host owns the shard and the write fails. Temporal's fencing token. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md

• Restate: the partition leader epoch, fenced at the log. https://docs.restate.dev/server/clusters
• Effect: a lease without a token. E/cluster/SqlRunnerStorage.ts

Shard controller — Per-History-host component that watches cluster membership and acquires or releases the shards it should own. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md

• Restate: PartitionProcessorManager driven by the cluster controller. https://docs.restate.dev/server/clusters
• Effect: the assignment loop in Sharding. E/cluster/Sharding.ts

Ringpop — Gossip-based membership (SWIM) with a consistent hash ring, one ring per service, used to find which host owns a shard, task-queue partition, or registry. https://github.com/temporalio/ringpop-go

• Restate: gossip failure detector plus the metadata store's nodes config. https://docs.restate.dev/server/clusters
• Effect: the cluster_runners table and a local hash ring. E/cluster/Sharding.ts

Transfer / timer / visibility / outbound / replication tasks — The task categories History writes in the same transaction as mutable state. Transfer tasks are immediate (dispatch to Matching, start a child, deliver a signal); timer tasks fire at a time; visibility tasks update the index; outbound tasks make Nexus and callback HTTP calls; replication tasks feed XDC. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md

• Restate: Actions emitted after applying a log record. https://docs.restate.dev/references/architecture
• Effect: persisted messages. E/cluster/MessageStorage.ts

Queue processor — The per-shard loop that reads one task category from its ack level, schedules tasks with priority and per-execution serialization, retries with backoff, and sends terminal failures to a dead-letter queue. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md

• Restate: the leader's action handling, timer service, and shuffle. https://docs.restate.dev/references/architecture
• Effect: the owner's storage poll. E/cluster/Sharding.ts

Ack level — The checkpointed position in a task category below which every task is complete, persisted in shard info so a new owner resumes from there. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md

• Restate: last_applied_lsn and the durable LSN used for trimming. https://docs.restate.dev/server/snapshots
• Effect: processed flag per message.

Buffered events — Events (signals, activity completions) that arrive while a Workflow Task is in flight. They are held and appended after the task completes so the worker's view stays consistent. https://github.com/temporalio/temporal/blob/main/docs/architecture/workflow-lifecycle.md

• Restate: notifications delivered on the open stream; no buffering needed. https://docs.restate.dev/references/architecture
• Effect: no analogue.

Speculative Workflow Task — A Workflow Task that is never persisted, used by Update so that a rejected Update costs zero database writes. https://github.com/temporalio/temporal/blob/main/docs/architecture/speculative-workflow-task.md

• Restate / Effect: no analogue.

Transient Workflow Task — A retried Workflow Task after a failure whose scheduled and started events are not written until it completes, so repeated failures do not bloat history. https://github.com/temporalio/temporal/blob/main/docs/architecture/workflow-lifecycle.md

• Restate: retry attempts are not journaled either. https://docs.restate.dev/develop/ts/error-handling
• Effect: no analogue.

Sticky queue — A Task Queue private to one worker so Workflow Tasks for cached executions return to it. See Sticky Execution. https://docs.temporal.io/sticky-execution

Sync match — Matching handing a task directly to a parked long-poller without writing it to the backlog. https://github.com/temporalio/temporal/blob/main/docs/architecture/matching-service.md

• Restate / Effect: no analogue.

Backlog / spool — Tasks persisted in the tasks table because no poller was waiting. https://github.com/temporalio/temporal/blob/main/docs/architecture/matching-service.md

• Restate: the inbox / virtual queue. https://docs.restate.dev/services/flow-control
• Effect: unprocessed messages. E/cluster/SqlMessageStorage.ts

Task queue partition — One of N physical sub-queues (default 4) of a Task Queue, arranged as a tree with forwarding to the root partition; the unit of Matching ownership. https://github.com/temporalio/temporal/blob/main/docs/architecture/matching-service.md

• Restate / Effect: no analogue.

Worker Versioning / Worker Deployment / Build ID — Mechanisms to route Workflow Tasks only to workers running compatible code. A Deployment Version is a named build; PINNED keeps an execution on its starting version, AUTO_UPGRADE moves it to the current one. https://docs.temporal.io/worker-versioning

• Restate: immutable deployments with invocation pinning. https://docs.restate.dev/services/versioning
• Effect: no analogue.

Patching (patched / deprecatePatch) — SDK markers written to history so new code can branch on whether an old execution has already passed a change point. https://docs.temporal.io/patching

• Restate: not needed because invocations pin to their deployment. https://docs.restate.dev/services/versioning
• Effect: no analogue.

HSM (hierarchical state machines) — The older framework for embedding typed state machines (callbacks, Nexus operations) inside mutable state. Being replaced by CHASM. https://github.com/temporalio/temporal/tree/main/service/history/hsm

• Restate / Effect: no analogue.

CHASM (Coordinated Heterogeneous Application State Machines) — A component-tree framework that lets non-workflow archetypes (standalone activities, schedules, callbacks) share the shard, routing, atomic-write, and replication substrate. https://github.com/temporalio/temporal/blob/main/docs/architecture/chasm.md

• Restate: the service kinds (Service, Virtual Object, Workflow) built on one partition state machine. https://docs.restate.dev/foundations/services
• Effect: Entity as the general actor. E/cluster/Entity.ts

Versioned transition — A (failover version, transition count) pair acting as the logical clock for mutable state and CHASM, used by replication and conflict resolution. https://github.com/temporalio/temporal/blob/main/docs/architecture/chasm.md

• Restate: LSN plus leader epoch. https://docs.restate.dev/references/architecture
• Effect: snowflake IDs. E/cluster/Snowflake.ts

Failover version / version history — Per-event version numbers tied to the active cluster so XDC can detect and resolve conflicting branches. https://docs.temporal.io/self-hosted-guide/multi-cluster-replication

• Restate / Effect: no analogue.

History branch / tree — An execution's events can fork on reset or conflict resolution; history_tree tracks branches and history_node stores event batches per branch. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md

• Restate / Effect: no analogue.

Dynamic config — Typed, hot-reloadable settings keyed by namespace, task queue, or shard, read from YAML. https://docs.temporal.io/references/dynamic-configuration

• Restate: hot-reloadable restate.toml. https://docs.restate.dev/references/server-config
• Effect: ShardingConfig. E/cluster/ShardingConfig.ts

System workflows — Temporal workflows the Worker service runs against the server itself (scanner, batcher, schedules V1, worker deployments, migrations). https://docs.temporal.io/temporal-service/temporal-server#worker-service

Message protocol (Update) — The worker-to-server protocol for Update requests, acceptance, and completion carried alongside Workflow Tasks. https://github.com/temporalio/temporal/blob/main/docs/architecture/message-protocol.md

B.2 Restate internals

Bifrost — Restate's replicated, segmented log abstraction. Each partition has one log, and that log is the write-ahead log for every state change in the partition. https://docs.restate.dev/references/architecture

• Temporal: no analogue; the database transaction log plays this role implicitly.
• Effect: no analogue.

Loglet — One segment of a Bifrost log with a fixed provider (in-memory, local RocksDB, or replicated). A log is a chain of loglets. https://docs.restate.dev/server/clusters

• Temporal / Effect: no analogue.

Sealing / chain extension — Making the current loglet read-only and appending a new loglet to the chain, used to reconfigure (new nodeset, new sequencer) or recover. Consensus is needed only on the metadata-store compare-and-swap that extends the chain. https://github.com/restatedev/restate/blob/main/crates/bifrost/src/bifrost_admin.rs

• Temporal / Effect: no analogue.

Sequencer — The single node ordering appends for a replicated loglet and replicating them to a write quorum of log-servers. https://docs.restate.dev/server/clusters

• Temporal / Effect: no analogue.

Nodeset / replication property — The log-server nodes a loglet writes to and how many must acknowledge. https://docs.restate.dev/server/clusters

Log-server — The node role that stores replicated loglet records in RocksDB. https://docs.restate.dev/server/overview

Metadata store — A Raft-replicated (or etcd, S3, DynamoDB backed) versioned key-value store holding nodes config, partition table, log chains, schema registry, and per-partition epochs. https://docs.restate.dev/server/metadata

• Temporal: cluster metadata and membership tables in the database, plus Ringpop. https://docs.temporal.io/temporal-service/temporal-server
• Effect: cluster_runners and cluster_locks. E/cluster/SqlRunnerStorage.ts

Partition / partition processor — A key range of the 64-bit partition key space and the state machine that applies that partition's log into RocksDB. https://docs.restate.dev/server/clusters

• Temporal: History Shard. https://docs.temporal.io/temporal-service/temporal-server#history-shard
• Effect: shard. E/cluster/ShardId.ts

Partition leader / leader epoch — The replica allowed to produce side effects. It claims a new epoch through the metadata store and announces itself by appending to the log; records from stale epochs are applied and ignored. https://docs.restate.dev/server/clusters

• Temporal: RangeID. See B.1.
• Effect: shard lease. E/cluster/RunnerStorage.ts

Partition store — Per-partition RocksDB with tables for invocation status, journal, key-value state, timers, inbox and outbox, promises, locks, deduplication, and FSM metadata. https://github.com/restatedev/restate/blob/main/crates/partition-store/src/keys.rs

• Temporal: the executions row family plus task tables. https://github.com/temporalio/temporal/blob/main/docs/architecture/history-service.md
• Effect: the two cluster tables. E/cluster/SqlMessageStorage.ts

Invocation — One durable execution of a handler, identified by an InvocationId, with a status lifecycle (scheduled, inboxed, invoked, suspended, paused, completed). https://docs.restate.dev/foundations/invocations

• Temporal: Workflow Execution. https://docs.temporal.io/workflow-execution
• Effect: execution. E/workflow/Workflow.ts

Journal — The invocation's ordered command and notification entries, stored in the partition store and replayed to the SDK on every attempt. https://docs.restate.dev/foundations/key-concepts

• Temporal: Event History. https://docs.temporal.io/workflow-execution/event#event-history
• Effect: reply rows. E/cluster/Reply.ts

Invoker — The leader-side component that drives invocations against endpoints over HTTP/2, replays the journal, forwards new commands to the state machine, and retries on failure. https://docs.restate.dev/references/architecture

• Temporal: Matching plus the worker's poll loop (inverted direction); Nexus outbound queue for the push case. https://docs.temporal.io/temporal-service/temporal-server#matching-service
• Effect: the owner's entity manager. E/cluster/internal/entityManager.ts

Service protocol — The versioned wire protocol (V1 to V7) between invoker and SDK: start message, commands, notifications, suspension, run completion proposals, acks. https://github.com/restatedev/restate/blob/main/service-protocol/dev/restate/service/protocol.proto

• Temporal: the gRPC Workflow Service API plus the sdk-core activation and completion types. https://docs.temporal.io/encyclopedia/architecture/temporal-sdks
• Effect: Effect RPC. E/cluster/Runners.ts

Deployment — An immutable registered endpoint (URL or Lambda ARN) discovered via /discover. Invocations pin to the deployment they started on. https://docs.restate.dev/services/versioning

• Temporal: Worker Deployment Version. https://docs.temporal.io/worker-versioning
• Effect: no analogue.

Schema registry — The metadata-store record of services, handlers, and deployments, also appended to each partition log so replicas agree on schema at the same point. https://docs.restate.dev/server/metadata

• Temporal: Nexus registry and task queue user data. https://docs.temporal.io/nexus/registry
• Effect: no analogue.

Service / Virtual Object / Workflow (Restate) — The three service kinds. Services are unkeyed and concurrent. Virtual Objects are keyed with K/V state and exclusive single-writer handlers plus shared read handlers. Workflows are keyed, single-run objects with a run handler, shared handlers, and durable promises. https://docs.restate.dev/foundations/services

• Temporal: Activity or stateless workflow; entity workflow; workflow with Update and Query handlers. https://docs.temporal.io/workflows
• Effect: entity RPC; entity; Workflow. E/cluster/Entity.ts

Exclusive / shared handler — On a Virtual Object or Workflow, exclusive handlers serialize per key; shared handlers run concurrently and may read state and promises. https://docs.restate.dev/foundations/handlers

• Temporal: Workflow Task versus Query. https://docs.temporal.io/sending-messages
• Effect: entity concurrency setting. E/cluster/Entity.ts

Virtual queue (vqueue) — Per-key or per-service admission queue with a lock and deficit-round-robin scheduling, on by default in v1.8; replaces the older inbox. https://docs.restate.dev/services/flow-control

• Temporal: per-workflow serialization in History plus Matching fairness. https://github.com/temporalio/temporal/blob/main/service/matching/fairness.md
• Effect: entity mailbox. E/cluster/Entity.ts

Inbox / outbox / shuffle — The inbox holds queued invocations for a locked key (legacy). The outbox holds cross-partition messages. The shuffle is the leader task that delivers outbox messages to other partitions. https://docs.restate.dev/references/architecture

• Temporal: transfer tasks. See B.1.
• Effect: persisted messages plus Notify. E/cluster/Sharding.ts

Awakeable — An ID handed to an external system that, when resolved or rejected, delivers a completion into the invocation's journal. https://docs.restate.dev/develop/ts/external-events

• Temporal: async activity completion by Task Token, or a Signal. https://docs.temporal.io/activity-execution#asynchronous-activity-completion
• Effect: DurableDeferred. E/workflow/DurableDeferred.ts

Durable promise — A named promise on a Workflow that any handler of that workflow key can resolve, reject, peek, or await. https://docs.restate.dev/develop/ts/external-events

• Temporal: a Signal handler feeding a Trigger, or an Update. https://docs.temporal.io/sending-messages
• Effect: DurableDeferred. E/workflow/DurableDeferred.ts

Idempotency key (Restate) — A request header that makes the invocation ID deterministic so retries attach to the same invocation and get its stored result. https://docs.restate.dev/services/invocation/http

• Temporal: Workflow ID with reuse and conflict policies, plus start request ID. https://docs.temporal.io/workflow-execution/workflowid-runid
• Effect: idempotencyKey(payload). E/workflow/Workflow.ts

Snapshot / trim — Periodic upload of a partition's RocksDB to object store, and truncation of the log below the durable LSN. https://docs.restate.dev/server/snapshots

• Temporal: retention deletion and archival. https://docs.temporal.io/temporal-service/archival
• Effect: no analogue.

Cluster controller — The admin-role component that places partition replica sets, picks leaders, seals and extends log chains, and triggers snapshots. https://docs.restate.dev/server/clusters

• Temporal: shard controller plus Ringpop; no single controller. See B.1.
• Effect: none; placement is a pure function of the runner table. E/cluster/Sharding.ts

restate-lite — An embeddable single-process server with a local loglet and one partition, used by restate dev. https://github.com/restatedev/restate/tree/main/lite

• Temporal: temporal server start-dev. https://docs.temporal.io/cli/server#start-dev
• Effect: SingleRunner. E/cluster/SingleRunner.ts

B.3 Effect Cluster internals

Runner — A process that registers in cluster_runners, owns shards, hosts entities, and serves the runner RPCs (Ping, Notify, Effect, Stream, Envelope). E/cluster/Runner.ts, E/cluster/Runners.ts

• Temporal: History host plus worker in one. https://docs.temporal.io/workers
• Restate: worker-role node plus the service endpoint in one. https://docs.restate.dev/server/overview

Shard / shard group — One of 300 hash buckets per group; an entity's shard is hash(entityId) % 300 + 1. Groups restrict entity types to subsets of runners. E/cluster/ShardId.ts, E/cluster/ShardingConfig.ts

• Temporal: History Shard. Restate: partition.

Hash ring assignment — Every runner computes shard placement locally from the runner table with a weighted consistent hash ring; there is no central shard manager in this snapshot. E/cluster/Sharding.ts

• Temporal: Ringpop ring. Restate: cluster controller scheduler.

Runner storage / shard lock — acquire, refresh, release on a shard, implemented as Postgres or MySQL advisory locks, or a cluster_locks row with 35-second expiry. A lease, not a fencing token. E/cluster/RunnerStorage.ts, E/cluster/SqlRunnerStorage.ts

• Temporal: RangeID (fenced). Restate: leader epoch (fenced).

Entity — The actor primitive: a type plus an ID with an RPC group as its interface, one RPC server per resident ID, serialized by default, reaped after idle time. E/cluster/Entity.ts

• Temporal: entity workflow or CHASM component. Restate: Virtual Object.

Entity address / envelope — (entityType, entityId, shardId) plus the wrapped request, interrupt, or ack-chunk message. E/cluster/EntityAddress.ts, E/cluster/Envelope.ts

• Temporal: (namespace, workflowId, runId) plus a history task. Restate: (partition key, invocation id) plus a log envelope.

Message storage — The cluster_messages and cluster_replies tables (or an in-memory driver). Persisted requests deduplicate on entityType/entityId/tag/primaryKey; replies are unique per (request_id, kind). E/cluster/MessageStorage.ts, E/cluster/SqlMessageStorage.ts

• Temporal: task tables plus history. Restate: log plus partition store.

Persisted vs volatile — A per-RPC annotation. Persisted requests go through storage (at-least-once); volatile ones go straight over the wire (at-most-once). E/cluster/ClusterSchema.ts

• Temporal: everything is persisted. Restate: everything through ingress is persisted.

Uninterruptible / WithTransaction / ShardGroup / DeliverAt — RPC annotations controlling interrupt handling, running the handler inside the storage transaction, placement, and delayed delivery. E/cluster/ClusterSchema.ts, E/cluster/DeliverAt.ts

Storage poll — The owner's loop claiming unprocessed messages for its shards (UPDATE ... FOR UPDATE), with last_read reclaim after 10 minutes and deliver_at filtering. E/cluster/SqlMessageStorage.ts

• Temporal: queue processors reading from the ack level. Restate: log read stream.

Notify — Best-effort RPC telling an owner that a persisted message was written so it polls sooner. E/cluster/Runners.ts

• Temporal: the in-memory notify channel feeding immediate queues. Restate: ingestion session to the leader.

Snowflake — A 64-bit time-ordered ID with a machine ID handed out by the runner table. E/cluster/Snowflake.ts

• Temporal: task IDs minted from the RangeID. Restate: ULID-based invocation IDs.

Singleton — An effect that runs on whichever runner owns the shard for its name. E/cluster/Singleton.ts

• Temporal: a system workflow with a fixed Workflow ID. Restate: a Virtual Object with a fixed key.

ClusterCron — Cron built from a singleton seed plus a self-rescheduling persisted run message. E/cluster/ClusterCron.ts

• Temporal: Schedule. Restate: delayed self-send.

WorkflowEngine — The interface (register, execute, poll, interrupt, resume, activityExecute, deferredResult, deferredDone, scheduleClock) with an in-memory implementation and the cluster implementation. E/workflow/WorkflowEngine.ts

• Temporal: the Workflow Service API plus sdk-core. Restate: the service protocol.

ClusterWorkflowEngine — Implements a workflow as entity type Workflow/<tag> with four persisted RPCs: run, activity, deferred, resume. E/cluster/ClusterWorkflowEngine.ts

WorkflowInstance — Per-run in-memory state (execution ID, scope, suspended, interrupted, abandoned, awaited and completed deferreds, activity state), rebuilt on every replay. E/workflow/WorkflowEngine.ts

• Temporal: the worker's cached workflow plus server mutable state. Restate: the SDK VM state plus invocation status.

Execution ID — sha256("<tag.length>:<tag>:<idempotencyKey(payload)>") truncated to 16 bytes; identical payloads always map to the same execution. E/workflow/Workflow.ts

• Temporal: Workflow ID. Restate: invocation ID from idempotency key.

Activity (Effect) — A named durable step whose result is memoized as the reply to the activity{name, attempt} request; runs on the owner runner. E/workflow/Activity.ts

• Temporal: Local Activity. Restate: ctx.run.

Attempt — A counter bumped by Activity.retry, part of the dedup key so each retry is its own durable request. E/workflow/Activity.ts

• Temporal: activity attempt number. Restate: retry count in StartMessage.

DurableDeferred — A named external completion slot. Awaiting it suspends the workflow; completing it by token wakes it. E/workflow/DurableDeferred.ts

• Temporal: Signal or async activity completion. Restate: awakeable or durable promise.

DurableClock — A sleep that is in-process under 60 seconds and a deliver_at message above it. E/workflow/DurableClock.ts

• Temporal: Timer. Restate: ctx.sleep.

DurableQueue — A persisted queue plus a deferred, for handing work to external consumers at-least-once. E/workflow/DurableQueue.ts

• Temporal: a Task Queue consumed by activity workers. Restate: Kafka subscription or one-way sends.

Suspend / Suspended result — The workflow self-interrupts, a Suspended reply is stored, and the run message is marked processed until something resets it. E/workflow/Workflow.ts

• Temporal: a workflow blocked with no in-flight task. Restate: SuspensionMessage and status Suspended.

Reset (clearReplies) — Deleting the run's exit reply and clearing processed and last_read so the storage poll redelivers the original run and the body replays. E/cluster/SqlMessageStorage.ts

• Temporal: scheduling a new Workflow Task. Restate: re-invoke after a notification.

SuspendOnFailure / CaptureDefects — References controlling whether failures become suspensions for manual resume, and whether defects are stored as results. E/workflow/Workflow.ts

• Temporal: Workflow Task failure retries forever by default, which is the closest "pause until fixed". Restate: PauseError and onMaxAttempts: pause.

Compensation — withCompensation registers finalizers on the workflow scope that run only if the final exit is a failure; rebuilt on replay. E/workflow/Workflow.ts

• Temporal: the saga pattern in user code. https://temporal.io/blog/saga-pattern-made-easy. Restate: saga guide. https://docs.restate.dev/guides/sagas

Abandon — Marking an instance as no longer owned (shard lost) so it skips parent resume and durable finalizers. E/cluster/internal/clusterAbandon.ts

• Temporal: shard ownership lost error. Restate: leader step-down.

WorkflowProxy — Generated RPC and HTTP groups (execute, discard, resume) exposing workflows to external callers. E/workflow/WorkflowProxy.ts

• Temporal: Frontend plus Temporal Client. Restate: ingress.

layerMemory / TestRunner / SingleRunner — The in-process engine, the all-in-memory cluster, and the one-process-plus-SQL cluster for tests and small deployments. E/workflow/WorkflowEngine.ts, E/cluster/TestRunner.ts, E/cluster/SingleRunner.ts

• Temporal: time-skipping test environment and dev server. https://docs.temporal.io/develop/typescript/testing-suite. Restate: testcontainers and restate-lite. https://docs.restate.dev/develop/ts/testing

B.4 Shared vocabulary

Journal and replay — The technique all three use: record the results of non-deterministic steps, re-run the code, and substitute recorded results so the code reaches the same point without redoing side effects. https://docs.temporal.io/temporal#durable-execution

Determinism — The requirement that workflow code issues the same durable steps in the same order on every replay. Enforced by Temporal, detected by Restate, assumed by Effect. https://docs.temporal.io/workflow-definition#deterministic-constraints

Fencing token — A monotonically increasing value a writer must present so a stale owner's writes are rejected. Temporal's RangeID and Restate's leader epoch are fencing tokens; Effect's lease is not. https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

Transactional outbox — Writing the intent to perform a side effect in the same transaction as the state change, then having a separate consumer perform it. Temporal's task rows, Restate's actions-from-log, and Effect's persisted messages are all instances. https://microservices.io/patterns/data/transactional-outbox.html

At-least-once / at-most-once / exactly-once — Delivery guarantees. All three deliver durable steps at least once; only side effects inside the same database transaction (Effect's WithTransaction) are exactly-once. https://docs.temporal.io/activity-definition#idempotency

Push vs pull dispatch — Whether the engine calls user code (Restate; Temporal for Nexus and callbacks) or user code polls the engine (Temporal workers). Effect runs both in one process. https://docs.temporal.io/task-queue

Single-writer — At most one in-flight mutation per key or execution. Temporal: one Workflow Task at a time. Restate: exclusive handlers via the vqueue lock. Effect: entity concurrency. https://docs.restate.dev/foundations/handlers

Log-first vs database-first — Whether the authoritative record is an ordered replicated log (Restate, fireline, firegrid) or rows in a database with conditional writes (Temporal, Effect). https://docs.restate.dev/references/architecture