Redis/Valkey and Temporal: Cache, Coordination and Durable Workflow Awareness

Three similar-looking needs, three different failure contracts

A web application has three complaints: catalog pages repeat database reads, six application instances need one shared rate-limit counter, and onboarding can spend six hours retrying calls to external services. The tempting response is “add Redis” for speed and “add Temporal” for reliability. That response is premature. A copied catalog value, a short-lived atomic counter, and a recoverable business process are different kinds of state. They differ in lifetime, authority, acceptable loss, recovery, and ownership.

Your deliverable is State/Cache/Workflow Technology Fit Matrix v1. It has three independent rows: CACHE, EPHEMERAL_COORDINATION, and DURABLE_WORKFLOW. Each row must name the problem, required semantics, measured trigger, simpler alternative, owner, migration cost, failure surface, evidence reference, decision, review date, and stop or pivot condition. Redis or Valkey may fit the first two rows; Temporal may fit the third. No platform inherits another row merely because it has a related feature. [REDISUSE] [VALKEYINTRO] [TEMPORAL]

The allowed outcomes include USE, PILOT, NOT_NOW, UNKNOWN, EVIDENCE_INCOMPLETE, OWNER_MISSING, REVIEW_REQUIRED, HOLD, PARTIAL, and DISPUTED. NOT_NOW is a complete decision only when the measured trigger is absent and a simpler alternative demonstrably meets the need. Missing evidence is not NOT_NOW.

Plan about 45 active minutes. You will classify the three needs, inspect one synthetic baseline, reject invalid shortcuts, run a deterministic offline lab, and recompute the decision for a multi-day reconciliation workflow.

This lesson is for engineers, technical leads, and product owners who must explain why Redis/Valkey or Temporal fits a bounded problem—or why it should not be introduced yet.

This is not an installation, configuration, migration, benchmarking, distributed-lock proof, or production deployment guide. It does not choose Redis versus Valkey, approve a Temporal rollout, or replace architecture and operations review.

Prerequisite probe: can you state why a technology capability and an adoption trigger are different claims, and why a named platform does not become mandatory merely because a system is growing?

If not, use this bounded bridge: classify the problem before naming a product; compare the smallest viable alternative; require measured evidence, an accountable owner, and an explicit failure boundary; preserve NOT_NOW when no trigger exists. This bridge supplies only the decision habit needed here. It does not claim completion of AWR-001.

Diagnose semantics before naming a platform

Answer these six checks before taking the fast path:

1. Can you explain why a cache value should normally be reconstructable from an authoritative source?
2. Can you distinguish planned TTL expiry from eviction under memory pressure?
3. Can you state the atomicity and failure behavior required by a shared counter or lease, rather than saying only “distributed lock”?
4. Can you distinguish retrying a background job from recovering a durable workflow with long-lived execution state?
5. Can you prove that the current application or database alternative misses a measured target?
6. Can you name the owner who operates the new stateful component and responds when it is stale, unavailable, partitioned, or replaying work?

Six of six supports the experienced route. Three to five means use the repair prompts. Zero to two means keep the field definitions visible through the whole lab. Every route retains the same evidence bar, negative cases, source boundary, and transfer task.

Self-check: do not use “in memory,” “persistent,” “distributed,” or “durable” as interchangeable labels. Ask what may be lost, what must survive, what may be replayed, how long state lives, and which system remains authoritative.

Mental model: classify state by lifetime and recovery

Use three separate chains:

CACHE → repeated-read problem → reconstructable copy → latency/freshness target → TTL + eviction tolerance → source of truth → simpler cache/query alternative → owner + cost/failure → bounded state

EPHEMERAL_COORDINATION → shared short-lived decision → atomicity/ordering need → TTL/lease semantics → partition and fallback behavior → database/application alternative → owner + cost/failure → bounded state

DURABLE_WORKFLOW → long-running business process → checkpoints + retry/recovery need → replay/history requirement → external-call and human-step boundary → job/database alternative → owner + cost/failure → bounded state

Redis documentation lists concrete patterns such as cache-aside, session storage, rate limiting, queues, Pub/Sub, and streams. Valkey describes an in-memory data-structure store with cache, message-broker, streaming, replication, TTL, eviction, and persistence capabilities. Temporal describes durable execution that resumes application workflows after failures. Those are capability facts, not adoption verdicts. [REDISUSE] [VALKEYINTRO] [TEMPORAL]

The ordered text above is the complete fallback for asset://AWR-002/AWR-002-ASSET-FLOW. If the visual is unavailable, no decision information is lost.

Evidence contract for three independent rows

CACHE

Record whether the proposed value is a reconstructable copy or authoritative state. Capture the read pattern, latency target, measured current latency, acceptable freshness, TTL, behavior on expiry, eviction tolerance, and recovery path. A cache may disappear or become stale by design; the application must know what happens next. A positive Redis/Valkey state therefore needs more than repeated reads. It needs a measured trigger, semantics that tolerate copied state, and evidence that a database query, index, HTTP cache, process-local cache, or other simpler option is insufficient.

EPHEMERAL_COORDINATION

Record the shared decision: counter, lease, deduplication token, short queue, or another bounded primitive. State whether operations must be atomic, the allowed TTL, whether early eviction is tolerable, what happens during network partition or failover, and whether durable history is required. “Use a distributed lock” is not an evidence record. A positive state must match the actual correctness requirement and define fail-open, fail-closed, retry, or fallback behavior.

DURABLE_WORKFLOW

Record workflow duration, external calls, human checkpoints, retry rules, recovery target, replay or history need, cancellation and compensation boundary, and the current job/database alternative. A task being asynchronous does not automatically require a workflow platform. A positive Temporal state needs a process whose required recovery semantics are not met by the simpler alternative, plus ownership for workflow code, workers, history growth, operational response, and safe external effects. [TEMPORAL]

Every row also carries technology, problem_class, simpler_alternative, simpler_alternative_result, operational_owner, migration_cost, failure_surface, evidence_ref, authority_refs, decision_state, learner-written rationale, review_due, and stop_or_pivot_trigger.

Building State/Cache/Workflow Technology Fit Matrix v1

Step 1 — Split the request into state contracts. “We need speed and reliability” is not a problem statement. Create one row for repeated reads, one for short-lived coordination, and one for process recovery. A system may need one, two, all three, or none.

Step 2 — Identify authority and acceptable loss. For a cache, name the source that can reconstruct the value. For coordination, name the correctness consequence of a lost or duplicated token. For a workflow, name the execution state and external effects that must survive a crash. If you cannot answer, use a typed incomplete state.

Step 3 — Measure the trigger against the current path. Compare the actual latency, throughput, contention, workflow duration, recovery time, or manual failure burden with a declared requirement. A product feature list is not a measurement. A hypothetical future problem does not justify a current positive decision.

Step 4 — Model TTL, eviction, and persistence independently. TTL is planned expiry. Eviction may remove data earlier under a policy or memory pressure. Persistence can reduce some loss modes, but it does not turn every in-memory record into an appropriate system of record. Replication changes availability and failure behavior; it does not erase consistency choices. [VALKEYINTRO]

Step 5 — Compare the smallest sufficient alternative. For cache, test query optimization, indexes, HTTP caching, and process-local caching. For coordination, test database atomic updates, unique constraints, or an existing queue. For workflow, test explicit state in the application database plus an idempotent job runner. “Simpler” means fewer new responsibilities while meeting the same measured need—not merely fewer lines of code.

Step 6 — Test platform fit. Redis/Valkey fit only when their data structures and lifetime/failure semantics match the cache or coordination row. Temporal fit is evaluated only against the durable-workflow row. A stream feature does not make a cache a durable business workflow, and a durable workflow engine is not a low-latency cache.

Step 7 — Make operations visible. Name ownership, monitoring, capacity, backup or persistence choices where applicable, upgrades, incident response, data recovery, cost, migration, and rollback. If no team accepts the obligation, OWNER_MISSING is more accurate than PILOT.

Step 8 — Choose the weakest state supported by evidence. USE and PILOT require complete positive evidence. NOT_NOW requires measured trigger absence and a sufficient alternative. UNKNOWN and EVIDENCE_INCOMPLETE preserve missing decisive evidence. REVIEW_REQUIRED, HOLD, PARTIAL, and DISPUTED require their visible basis rather than a vague sense of caution.

Step 9 — Bind reconsideration. Each row names a review date and a stop or pivot trigger: for example, “reopen when database p95 exceeds 80 ms for 14 days,” “stop the pilot if counter loss violates the declared limit,” or “revisit Temporal when workflow duration and manual recovery exceed the current job runner’s bound.”

Worked example: one system, three different decisions

All numbers below are synthetic. They teach decision structure, not product performance.

Catalog cache. The target is p95 ≤ 80 ms; the measured PostgreSQL path is p95 = 24 ms. Catalog values can be reconstructed, a ten-minute freshness window is acceptable, and a process-local cache already handles bursts. The trigger for another stateful service is measured absent. The row is NOT_NOW, not UNKNOWN, because the relevant evidence exists and the current alternative meets the target.

Shared rate-limit counter. Six application instances must atomically increment one 60-second counter. The declared target is p95 ≤ 10 ms; the tested database counter is p95 = 38 ms. Early eviction would violate the limit, but durable historical replay is unnecessary. A platform team owns a bounded experiment and defines fail-closed or bounded fallback behavior. Redis/Valkey becomes PILOT, not automatic USE: the trigger and semantic fit are present, but operational behavior must be tested. Redis documents rate limiting as a supported use case, and Valkey exposes relevant in-memory data structures, TTL, replication, eviction, and persistence options. [REDISUSE] [VALKEYINTRO]

Six-hour onboarding. The current database-backed runner stores checkpoints, retries idempotent external calls, and meets its recovery objective. There is no human checkpoint, multi-day duration, or unmet replay/history requirement. Temporal remains NOT_NOW: the capability is real, but the current need does not outrun the simpler alternative. [TEMPORAL]

Now mutate the cache row: the “cached” record becomes the only authoritative copy and cannot be reconstructed. A normal cache decision is invalid even if latency is excellent. Authority, eviction, persistence, backup, and recovery must be redesigned; do not quietly relabel the same row as USE.

The structured worked example is asset://AWR-002/AWR-002-ASSET-TABLE; its locale tables and JSON retain every decisive field.

Common failure modes

1. One “fast state” bucket. Cache, coordination, queueing, and workflow are grouped together. Repair: split the rows and state lifetime, authority, and recovery separately.
2. Capability becomes adoption evidence. A documented Redis, Valkey, or Temporal feature is treated as proof of local need. Repair: return to the measured trigger and current alternative. [REDISUSE] [VALKEYINTRO] [TEMPORAL]
3. Authoritative data is called a cache. The only copy may be evicted or expire. Repair: restore a source of truth or redesign the persistence/recovery contract before choosing a product.
4. TTL equals eviction. Planned expiry is confused with early removal. Repair: record both fields and test the consequence of each.
5. A lock name replaces correctness reasoning. Atomicity, lease expiry, fencing, partition behavior, and fallback are absent. Repair: express the concrete shared decision and its failure consequence.
6. Any retry means Temporal. A five-minute idempotent job is treated as a durable workflow trigger. Repair: compare duration, checkpoints, recovery, history, human steps, and current runner evidence.
7. Temporal becomes a cache or Redis becomes a workflow engine. Related features erase the owned boundary. Repair: restore the three independent chains.
8. Unknown becomes NOT_NOW. Missing latency, owner, or recovery evidence is silently treated as absence. Repair: use EVIDENCE_INCOMPLETE, UNKNOWN, or another justified typed state.
9. Ownerless positive state. No team owns persistence settings, upgrades, monitoring, recovery, or workflow behavior. Repair: remain OWNER_MISSING until a real owner accepts the obligation.
10. One platform decision is copied into transfer. The new system’s evidence is ignored. Repair: recompute every row from the new fixture.

Experienced bridge: do not compress semantics

If you have operated Redis, Valkey, or Temporal, shorten definitions—but keep the evidence fields. For a cache, state what is authoritative, what may be stale or lost, the measured miss on the current path, and how the application behaves on cache failure. For coordination, state the exact atomicity or ordering property, TTL or lease behavior, partition policy, and correctness impact. For a workflow, state duration, checkpoint and recovery requirements, external side effects, history/replay need, and why the current runner cannot meet them.

Operational familiarity can create a bias toward a known platform. Counter it with a reversal test: what exact observation would move your positive state back to NOT_NOW, or move NOT_NOW to PILOT? If the answer is “team preference” or “we already use it elsewhere,” the decision is not bounded.

Also separate product selection from problem fit. This lesson may conclude that an in-memory data-structure platform or a durable workflow platform fits a row. It does not decide licensing, managed versus self-hosted operation, vendor, topology, sizing, or rollout architecture. Those choices need their own authority and evidence.

Measure the simpler alternative before adding a platform

Application/database path versus Redis or Valkey for cache

Query tuning, indexes, materialized views, HTTP caching, and process-local caches may meet the target without a shared service. A shared Redis/Valkey layer can offer useful data structures and cache patterns, but it adds network dependency, capacity and eviction behavior, persistence choices, replication/failover behavior, monitoring, upgrades, and invalidation design. [REDISUSE] [VALKEYINTRO] The right question is whether those obligations buy a measured improvement that the smaller path cannot provide.

Database constraints versus Redis or Valkey for coordination

A unique constraint, atomic update, advisory mechanism, or existing queue may already express the required shared decision. A fast shared counter may justify a bounded Redis/Valkey pilot when the database path misses latency or contention targets. A correctness-sensitive lease may require deeper analysis than “atomic command available.” Keep the consequence of duplicate work, early expiry, split ownership, and outage fallback explicit.

Database-backed job runner versus Temporal

An application table plus idempotent workers can be a good fit for short, bounded jobs. Temporal’s official documentation describes recoverable durable execution across failures and long periods, but adopting it adds a programming model, workers, operational ownership, deployment, visibility, history, and safe-side-effect responsibilities. [TEMPORAL] Prefer it only when those semantics solve an evidenced workflow problem that the current runner does not meet.

The trade-off is not “old stack versus modern stack.” It is the smallest additional state contract that meets the real requirement while keeping authority, loss, recovery, ownership, and failure behavior reviewable.

Guided and independent practice

Use the offline lab at lab://AWR-002/AWR-002-LAB1. It needs only a standard Python interpreter. All fixtures are synthetic and read-only; there are no accounts, credentials, customer records, network calls, or infrastructure changes. The starter exposes the evidence fields and checking rules but leaves decisions, rationales, review dates, and stop conditions blank.

Guided pass:

1. Select AWR002-BASELINE-001.
2. Create exactly three records: CACHE, EPHEMERAL_COORDINATION, and DURABLE_WORKFLOW.
3. Copy each evidence object exactly from the fixture; do not improve or infer missing values.
4. Choose a state no stronger than the visible evidence.
5. Write a rationale that cites the decisive field, the simpler alternative, and the failure or ownership boundary.
6. Add review_due and a measurable stop_or_pivot_trigger.
7. Run python run_checks.py evidence/decision_matrix.template.json after replacing the placeholders.

Independent pass: test authoritative non-reconstructable cache data, a multi-day workflow with manual checkpoints, a workflow with recovery need removed, missing decisive evidence, and missing ownership. A failed rule should lead back to a visible field—not to an answer key.

For transfer, use the separate reconciliation fixture. It has no meaningful cache pressure but does have a multi-day process, manual checkpoints, retryable external calls, and a replay/history requirement. Recompute all three rows. Redis/Valkey may remain NOT_NOW while Temporal moves toward PILOT; the changed evidence, not the lesson narrative, must justify that result.

What makes the evidence package acceptable?

A reviewer must reconstruct the result without hidden reasoning. For CACHE, they can see authority, reconstructability, read pattern, latency target and measurement, TTL, eviction tolerance, freshness, simpler alternative, owner, cost, and failure behavior. For EPHEMERAL_COORDINATION, they can see the shared primitive, atomicity need, TTL or lease, partition/fallback behavior, durability boundary, measured trigger, and correctness consequence. For DURABLE_WORKFLOW, they can see duration, checkpoints, retries, recovery, replay/history, external effects, simpler runner, owner, migration cost, and failure surface.

authority_refs keep source roles explicit. REDISUSE supports bounded Redis use-case facts; VALKEYINTRO supports Valkey’s in-memory data structures and options such as TTL, eviction, replication, and persistence; TEMPORAL supports the durable-execution and recovery boundary. AWR-002-K4 supplies the MAKNOW design gate. [REDISUSE] [VALKEYINTRO] [TEMPORAL]

The checker verifies exact fixture binding, state vocabulary, positive-state prerequisites, legitimate NOT_NOW, typed non-success basis, ownership, cost/failure evidence, and authority trace. It does not contain a hidden expected-decision table. AI may organize supplied evidence and run deterministic comparisons, but it may not invent latency, ownership, recovery need, adoption approval, or migration success.

Assessment and transfer

AWR-002-F1: state the owned boundary and one adjacent non-goal. A passing answer distinguishes cache/ephemeral coordination/durable workflow awareness from deployment and from the neighboring Kubernetes/Kafka and search/API lessons.

AWR-002-F2: diagnose the mutation that turns a reconstructable cached catalog copy into authoritative non-reconstructable records. Name the invalidated fields, consequence, and minimum repair.

AWR-002-F3: recompute the reconciliation transfer case rather than copying the baseline.

AWR-002-S1: explain the lesson boundary and one non-goal in your own words.

AWR-002-S2: build the complete three-row State/Cache/Workflow Technology Fit Matrix v1 from the baseline fixture.

AWR-002-S3: diagnose the authoritative-cache mutation. “Enable persistence” alone is not sufficient; the answer must restore authority, loss, eviction, backup, and recovery reasoning.

AWR-002-S4: the second system has no meaningful cache pressure but runs financial reconciliation for several days, includes manual checkpoints and retryable external calls, and requires recoverable history. Recompute every row. Explain why Temporal may become a bounded PILOT while Redis/Valkey stays NOT_NOW.

Transfer passes only when the new decision traces to the new evidence. “Temporal is made for workflows” states capability; it does not complete the local problem-fit, alternative, owner, cost, and stop-condition argument.

Sources and freshness boundary

REDISUSE — official Redis use-case documentation. It supports bounded capability facts for patterns such as rate limiting, session storage, cache-aside, queues, Pub/Sub, and streams. It does not prove that this application needs Redis. [REDISUSE]

VALKEYINTRO — official Valkey introduction. It supports the bounded description of Valkey as an open-source in-memory data-structure store used as a database, cache, message broker, and streaming engine, with replication, TTL, eviction, and persistence options. It does not prove semantic fit or operational readiness here. [VALKEYINTRO]

TEMPORAL — official Temporal documentation. It supports the bounded claim that Temporal provides durable execution intended to resume workflows after crashes, network failures, or infrastructure outages. It does not prove that a particular asynchronous job needs Temporal. [TEMPORAL]

These official sources were rechecked on 2026-09-12; no material change required expanding or rewriting the frozen claim boundaries. The next scheduled review remains 2026-12-02, or earlier if the cited platform semantics materially change. External documentation remains FACT authority for capability. Trigger thresholds, decision labels, ownership requirements, and adoption gates remain MAKNOW DESIGN authority.