Redis/Valkey و Temporal: Cache/Coordination/Workflow Awareness

سه نیاز شبیه‌به‌هم، سه قرارداد شکست متفاوت

یک برنامه‌ی وب سه نشانه دارد: صفحه‌های catalog مرتب queryهای یکسان به database می‌فرستند، شش instance برنامه باید یک rate-limit counter مشترک داشته باشند، و فرایند onboarding گاهی شش ساعت میان چند سرویس خارجی retry می‌شود. پاسخ عجولانه این است که «برای سرعت Redis اضافه کنیم» و «برای reliability سراغ Temporal برویم». اما یک نسخه‌ی قابل‌بازسازی از catalog، یک counter اتمیک کوتاه‌عمر و state یک فرایند کسب‌وکار قابل‌بازیابی، یک چیز نیستند. عمر، مرجع اصلی، تحمل از‌دست‌رفتن، recovery و مالک عملیاتی آن‌ها فرق دارد.

خروجی این درس State/Cache/Workflow Technology Fit Matrix v1 است. Matrix سه row مستقل دارد: CACHE، EPHEMERAL_COORDINATION و DURABLE_WORKFLOW. در هر row باید problem، semantics لازم، trigger اندازه‌گیری‌شده، simpler alternative، owner، migration cost، failure surface، evidence ref، decision، تاریخ review و stop/pivot condition ثبت شود. Redis یا Valkey ممکن است برای دو row اول مناسب باشند؛ Temporal فقط در row سوم بررسی می‌شود. داشتن یک feature مرتبط اجازه نمی‌دهد platform مسئولیت row دیگری را هم به ارث ببرد. [REDISUSE] [VALKEYINTRO] [TEMPORAL]

stateهای مجاز عبارت‌اند از USE، PILOT، NOT_NOW، UNKNOWN، EVIDENCE_INCOMPLETE، OWNER_MISSING، REVIEW_REQUIRED، HOLD، PARTIAL و DISPUTED. فقط وقتی trigger با measurement غایب است و alternative ساده‌تر نیاز را پوشش می‌دهد، NOT_NOW یک تصمیم کامل است. نبود evidence را نباید NOT_NOW نامید.

برای درس حدود ۴۵ دقیقه فعالیت در نظر بگیرید: سه نیاز را classify می‌کنید، baseline مصنوعی را می‌سنجید، shortcutهای غلط را رد می‌کنید، lab آفلاین deterministic را اجرا می‌کنید و برای یک reconciliation چندروزه تصمیم را از نو می‌سازید.

این درس برای engineer، technical lead یا product owner است که باید بتواند با evidence توضیح دهد Redis/Valkey یا Temporal دقیقاً برای کدام مسئله مناسب است—یا چرا فعلاً نباید اضافه شود.

این متن راهنمای نصب، configuration، migration، benchmark، اثبات distributed lock یا deployment در production نیست. میان Redis و Valkey انتخاب vendor نمی‌کند، rollout Temporal را تصویب نمی‌کند و جای architecture/operations review را نمی‌گیرد.

پیش‌نیاز: آیا می‌توانید فرق «این technology چنین قابلیتی دارد» و «سیستم ما trigger لازم برای پذیرش آن را دارد» توضیح دهید؟ آیا می‌توانید نشان دهید رشد سیستم به‌تنهایی هیچ platform مشخصی را اجباری نمی‌کند؟

اگر پاسخ روشن نیست، از این bridge محدود استفاده کنید: ابتدا problem را classify کنید؛ کوچک‌ترین alternative کافی را بسنجید؛ measurement، owner و failure boundary بخواهید؛ و وقتی trigger وجود ندارد NOT_NOW را حفظ کنید. این bridge فقط عادت تصمیم‌گیری لازم برای همین درس را فراهم می‌کند و ادعا نمی‌کند AWR-001 تکمیل شده است.

اول semantics را تشخیص دهید، بعد platform را

قبل از انتخاب Fast Path به شش سؤال جواب دهید:

1. چرا مقدار cache باید معمولاً از یک source معتبر قابل‌بازسازی باشد؟
2. فرق expiry برنامه‌ریزی‌شده با TTL و eviction ناشی از memory pressure چیست؟
3. برای counter یا lease مشترک دقیقاً چه atomicity و failure behavior لازم است؟
4. چه تفاوتی میان retry یک background job و recovery یک durable workflow با state بلندعمر وجود دارد؟
5. آیا با عدد و measurement نشان داده‌اید مسیر فعلی application/database از target عقب است؟
6. اگر component جدید stale، unavailable، partitioned یا در حال replay شد، چه owner مشخصی پاسخ‌گو است؟

۶/۶ یعنی Experienced Path مناسب است. ۳ تا ۵ یعنی Repair Path و promptهای دقیق‌تر را نگه دارید. ۰ تا ۲ یعنی Foundation Path و تعریف fieldها تا پایان lab باید visible بماند. هیچ routeای evidence bar، negative case، source boundary یا transfer را حذف نمی‌کند.

Self-check: واژه‌های «in-memory»، «persistent»، «distributed» و «durable» را مترادف فرض نکنید. بپرسید چه چیزی می‌تواند از بین برود، چه چیزی باید survive کند، چه چیزی باید replay شود، state چه مدت زنده است و authority اصلی دست کدام سیستم می‌ماند.

مدل ذهنی: state را بر اساس عمر و recovery طبقه‌بندی کنید

سه chain را مستقل نگه دارید:

CACHE → مسئله‌ی read تکراری → نسخه‌ی قابل‌بازسازی → target latency/freshness → TTL + eviction tolerance → source of truth → alternative ساده‌تر → owner + cost/failure → bounded state

EPHEMERAL_COORDINATION → تصمیم مشترک کوتاه‌عمر → نیاز atomicity/ordering → TTL/lease semantics → partition و fallback → alternative application/database → owner + cost/failure → bounded state

DURABLE_WORKFLOW → فرایند کسب‌وکار بلندمدت → checkpoint + retry/recovery → نیاز replay/history → مرز external call و human step → alternative job/database → owner + cost/failure → bounded state

مستندات Redis الگوهایی مثل cache-aside، session storage، rate limiting، queue، Pub/Sub و stream را نشان می‌دهد. معرفی رسمی Valkey آن را in-memory data-structure store با کاربردهای cache، message broker و streaming و قابلیت‌هایی مانند TTL، eviction، replication و persistence معرفی می‌کند. مستندات Temporal درباره durable execution و ادامه‌ی workflow پس از failure صحبت می‌کند. این‌ها FACT مربوط به capability هستند، نه حکم adoption برای سیستم ما. [REDISUSE] [VALKEYINTRO] [TEMPORAL]

همین chainها text-equivalent کامل asset://AWR-002/AWR-002-ASSET-FLOW هستند؛ نبود renderer چیزی از منطق تصمیم کم نمی‌کند.

Evidence Contract برای سه row مستقل

CACHE

اول بنویسید مقدار پیشنهادی نسخه‌ای reconstructable است یا authoritative state. read pattern، target latency، measurement فعلی، freshness قابل‌قبول، TTL، رفتار بعد از expiry، eviction tolerance و recovery path را ثبت کنید. cache ممکن است به‌طور طراحی‌شده stale یا خالی شود؛ application باید بداند بعدش چه می‌کند. بنابراین read تکراری به‌تنهایی state مثبت برای Redis/Valkey نمی‌سازد. trigger اندازه‌گیری‌شده، تحمل copied state و ناتوانی alternativeهایی مثل query tuning، index، HTTP cache یا process-local cache باید visible باشد.

EPHEMERAL_COORDINATION

خود تصمیم مشترک را نام ببرید: counter، lease، deduplication token، queue کوتاه‌عمر یا primitive محدود دیگر. مشخص کنید operation باید atomic باشد یا نه، TTL چقدر است، early eviction چه پیامدی دارد، در network partition/failover چه می‌شود و آیا history بادوام لازم است. جمله‌ی «distributed lock می‌گذاریم» evidence نیست. state مثبت فقط وقتی معتبر است که correctness requirement، expiry و رفتار fail-open، fail-closed، retry یا fallback دقیق باشند.

DURABLE_WORKFLOW

workflow duration، external callها، human checkpoint، retry rule، recovery target، replay/history، cancellation/compensation boundary و alternative فعلی job/database را بنویسید. asynchronous بودن task مساوی نیاز به workflow platform نیست. state مثبت Temporal به فرایندی نیاز دارد که semantics بازیابی آن از توان alternative ساده‌تر خارج باشد؛ علاوه بر آن، مالک workflow code، workerها، history growth، incident response و safe external effect باید روشن باشد. [TEMPORAL]

هر سه row همچنین technology، problem_class، simpler_alternative، نتیجه‌ی آزمون alternative، operational_owner، migration_cost، failure_surface، evidence_ref، authority_refs، decision_state، rationale نوشته‌شده توسط learner، review_due و stop_or_pivot_trigger دارند.

ساخت State/Cache/Workflow Technology Fit Matrix v1

گام ۱ — درخواست مبهم را به state contract تبدیل کنید. «سرعت و reliability می‌خواهیم» problem statement نیست. برای read تکراری، هماهنگی کوتاه‌عمر و recovery فرایند سه row بسازید. یک سیستم می‌تواند یکی، چندتا یا هیچ‌کدام را لازم داشته باشد.

گام ۲ — authority و acceptable loss را مشخص کنید. در cache، source بازسازنده را نام ببرید. در coordination، پیامد گم‌شدن یا duplicate شدن token را بنویسید. در workflow، execution state و external effectهایی را تعیین کنید که باید از crash عبور کنند. پاسخ نامعلوم یعنی typed incomplete state، نه حدس.

گام ۳ — trigger را علیه مسیر فعلی اندازه بگیرید. latency، throughput، contention، workflow duration، recovery time یا manual failure burden واقعی را با requirement از پیش نوشته‌شده مقایسه کنید. feature list محصول measurement نیست. مشکلی که شاید روزی رخ دهد adoption امروز را justify نمی‌کند.

گام ۴ — TTL، eviction و persistence را جدا مدل کنید. TTL expiry برنامه‌ریزی‌شده است؛ eviction ممکن است به‌دلیل policy یا memory pressure زودتر داده را حذف کند. persistence بعضی loss modeها را کم می‌کند، ولی هر record در حافظه را به system of record مناسب تبدیل نمی‌کند. replication availability و failure behavior را عوض می‌کند؛ consistency choice را حذف نمی‌کند. [VALKEYINTRO]

گام ۵ — کوچک‌ترین alternative کافی را آزمایش کنید. برای cache، query optimization، index، HTTP caching و process-local cache را بسنجید. برای coordination، atomic update، unique constraint یا queue موجود را امتحان کنید. برای workflow، application database همراه job runner idempotent را مقایسه کنید. «ساده‌تر» یعنی مسئولیت جدید کمتر با همان requirement؛ نه صرفاً code line کمتر.

گام ۶ — platform fit را بررسی کنید. Redis/Valkey فقط وقتی candidate هستند که data structure و lifetime/failure semantics آن‌ها با row cache یا coordination جور باشد. Temporal فقط با durable-workflow row سنجیده می‌شود. stream feature یک cache را به business workflow بادوام تبدیل نمی‌کند؛ workflow engine هم low-latency cache نیست.

گام ۷ — عملیات را visible کنید. owner، monitoring، capacity، persistence/backup choice در صورت نیاز، upgrade، incident response، recovery، cost، migration و rollback را ثبت کنید. وقتی هیچ تیمی این تعهد را نمی‌پذیرد، OWNER_MISSING از PILOT دقیق‌تر است.

گام ۸ — ضعیف‌ترین state سازگار با evidence را انتخاب کنید. USE و PILOT evidence مثبت کامل می‌خواهند. NOT_NOW فقط با غیبت اندازه‌گیری‌شده‌ی trigger و alternative کافی درست است. UNKNOWN و EVIDENCE_INCOMPLETE نبود evidence تعیین‌کننده را حفظ می‌کنند. REVIEW_REQUIRED، HOLD، PARTIAL و DISPUTED نیز باید basis visible خود را داشته باشند.

گام ۹ — شرط بازبینی را ببندید. هر row یک تاریخ review و trigger توقف یا تغییر دارد؛ مثلاً «اگر p95 database برای ۱۴ روز از ۸۰ms گذشت بازبینی کن»، «اگر pilot counter بیش از حد مجاز state از دست داد متوقف کن» یا «وقتی duration و recovery دستی از bound runner فعلی گذشت Temporal را دوباره بررسی کن».

Worked Example: یک سیستم، سه تصمیم متفاوت

تمام عددهای این مثال synthetic هستند و درباره performance واقعی هیچ محصولی claim نمی‌سازند.

Catalog cache. target برابر p95 ≤ 80ms است و PostgreSQL فعلی p95 = 24ms دارد. catalog از source اصلی قابل‌بازسازی است، freshness ده‌دقیقه‌ای پذیرفته می‌شود و process-local cache spikeها را پوشش می‌دهد. trigger برای یک stateful service جدید measured absent است. decision برابر NOT_NOW است، نه UNKNOWN؛ چون evidence لازم وجود دارد و alternative فعلی target را می‌زند.

Rate-limit counter مشترک. شش instance باید یک counter شصت‌ثانیه‌ای را atomic افزایش دهند. target برابر p95 ≤ 10ms است اما database counter در fixture به p95 = 38ms می‌رسد. early eviction مجاز نیست، ولی historical replay لازم نداریم. platform team یک experiment محدود را own می‌کند و fail-closed یا fallback محدود را تعریف کرده است. Redis/Valkey به PILOT می‌رود، نه USE: trigger و semantic fit دیده می‌شود، اما رفتار عملیاتی هنوز باید آزموده شود. Redis rate limiting را به‌عنوان use case مستند می‌کند و Valkey data structure، TTL، replication، eviction و persistence optionهای مرتبط دارد. [REDISUSE] [VALKEYINTRO]

Onboarding شش‌ساعته. runner مبتنی بر database checkpoint را ذخیره می‌کند، external callها idempotent هستند و recovery objective فعلی پاس می‌شود. human checkpoint، duration چندروزه یا replay/history requirement برآورده‌نشده نداریم. Temporal NOT_NOW می‌ماند؛ capability آن واقعی است، اما نیاز جاری از alternative ساده‌تر عبور نکرده است. [TEMPORAL]

حالا cache row را mutate کنید: record به تنها نسخه‌ی authoritative و غیرقابل‌بازسازی تبدیل می‌شود. حتی با latency عالی، قرارداد معمول cache invalid است. authority، eviction، persistence، backup و recovery باید دوباره طراحی شوند؛ همان row را بی‌صدا USE نکنید.

نسخه‌ی structured این مثال asset://AWR-002/AWR-002-ASSET-TABLE است و projectionهای FA/EN و JSON آن همه‌ی fieldهای تعیین‌کننده را نگه می‌دارند.

Failure Modeهای رایج

1. همه‌چیز یک fast-state فرض می‌شود. cache، coordination، queue و workflow مخلوط می‌شوند. Repair: rowها را جدا کنید و lifetime، authority و recovery را برای هرکدام بنویسید.
2. Capability به adoption evidence تبدیل می‌شود. وجود feature در Redis، Valkey یا Temporal نیاز محلی را اثبات‌شده فرض می‌کند. Repair: measured trigger و alternative فعلی را دوباره ببینید. [REDISUSE] [VALKEYINTRO] [TEMPORAL]
3. داده‌ی authoritative را cache می‌نامیم. تنها نسخه ممکن است expire یا evict شود. Repair: source of truth را برگردانید یا persistence/recovery contract را پیش از product choice بازطراحی کنید.
4. TTL و eviction یکی فرض می‌شوند. Repair: هر دو field و پیامد هرکدام را جدا ثبت و آزمایش کنید.
5. اسم lock جای correctness reasoning را می‌گیرد. atomicity، lease expiry، fencing، partition و fallback غایب‌اند. Repair: shared decision و failure consequence واقعی را بنویسید.
6. هر retry یعنی Temporal. job پنج‌دقیقه‌ای idempotent، durable-workflow trigger فرض می‌شود. Repair: duration، checkpoint، recovery، history، human step و evidence runner فعلی را مقایسه کنید.
7. Temporal نقش cache یا Redis نقش workflow engine می‌گیرد. featureهای مجاور boundary را پاک می‌کنند. Repair: سه chain مستقل را restore کنید.
8. Unknown به NOT_NOW تبدیل می‌شود. latency، owner یا recovery evidence گم است اما decision بسته می‌شود. Repair: EVIDENCE_INCOMPLETE، UNKNOWN یا typed state مناسب را نگه دارید.
9. Positive state بدون owner. هیچ تیمی persistence setting، upgrade، monitoring، recovery یا workflow behavior را own نمی‌کند. Repair: تا پذیرش owner واقعی OWNER_MISSING بمانید.
10. جواب baseline در transfer کپی می‌شود. Repair: هر row را فقط از fixture جدید recompute کنید.

Bridge افراد باتجربه: semantics را فشرده نکنید

اگر Redis، Valkey یا Temporal را در production اداره کرده‌اید، تعریف‌های مقدماتی را کوتاه کنید ولی fieldهای evidence را حذف نکنید. برای cache بگویید authority کجاست، چه چیزی می‌تواند stale یا lost شود، مسیر فعلی دقیقاً کدام target را نمی‌زند و application در cache failure چه می‌کند. برای coordination، atomicity/ordering property، TTL یا lease، partition policy و correctness impact را روشن کنید. برای workflow، duration، checkpoint/recovery، external side effect، history/replay و ناتوانی runner فعلی را نشان دهید.

تجربه‌ی عملی ممکن است شما را به platform آشنا متمایل کند. reversal test بزنید: چه observation دقیقی state مثبت را به NOT_NOW برمی‌گرداند، یا NOT_NOW را به PILOT می‌برد؟ اگر پاسخ «تیم دوستش دارد» یا «جای دیگری استفاده می‌کنیم» باشد، decision bounded نیست.

Problem fit را از product selection جدا کنید. این درس شاید نشان دهد in-memory data-structure platform یا durable workflow platform برای یک row مناسب است، اما license، managed/self-hosted، vendor، topology، sizing و rollout architecture را تعیین نمی‌کند. آن‌ها authority و evidence مستقل می‌خواهند.

قبل از platform جدید، alternative ساده‌تر را بسنجید

مسیر application/database در برابر Redis یا Valkey برای cache

query tuning، index، materialized view، HTTP caching و process-local cache ممکن است بدون shared service target را پوشش دهند. Redis/Valkey data structure و cache patternهای مفیدی دارند، اما network dependency، capacity/eviction behavior، persistence choice، replication/failover، monitoring، upgrade و invalidation design اضافه می‌کنند. [REDISUSE] [VALKEYINTRO] سؤال درست این است که آیا این مسئولیت‌ها بهبود اندازه‌گیری‌شده‌ای می‌خرند که مسیر کوچک‌تر قادر به ارائه‌اش نیست.

database constraint در برابر Redis یا Valkey برای coordination

unique constraint، atomic update، advisory mechanism یا queue موجود ممکن است shared decision را بیان کند. وقتی مسیر database از latency/contension target عقب است، shared counter سریع می‌تواند pilot محدود را justify کند. اما lease حساس به correctness تحلیل عمیق‌تری از «یک atomic command داریم» می‌خواهد. duplicate work، early expiry، split ownership و outage fallback را visible نگه دارید.

DB-backed job runner در برابر Temporal

application table همراه worker idempotent می‌تواند برای job کوتاه و bounded مناسب باشد. مستندات Temporal durable execution قابل‌بازیابی پس از failure و در بازه‌های طولانی را توصیف می‌کند، اما adoption آن programming model، worker، deployment، observability، history و safe-side-effect responsibility می‌آورد. [TEMPORAL] فقط وقتی آن را ترجیح دهید که این semantics مشکل اثبات‌شده‌ای را حل کند که runner فعلی پوشش نمی‌دهد.

trade-off میان stack قدیمی و مدرن نیست؛ میان کوچک‌ترین state contract کافی و مسئولیت‌های authority، loss، recovery، owner و failure است.

Guided Practice و Independent Practice

lab آفلاین lab://AWR-002/AWR-002-LAB1 فقط به Python استاندارد نیاز دارد. همه‌ی fixtureها synthetic و read-only هستند؛ account، credential، customer record، network call یا infrastructure mutation نداریم. starter تمام evidence fieldها و ruleها را نشان می‌دهد، اما decision، rationale، review date و stop condition را خالی می‌گذارد.

Guided pass:

1. fixture AWR002-BASELINE-001 را انتخاب کنید.
2. دقیقاً سه record بسازید: CACHE، EPHEMERAL_COORDINATION و DURABLE_WORKFLOW.
3. evidence object هر row را بدون بهبود یا inference دقیقاً کپی کنید.
4. stateای قوی‌تر از evidence انتخاب نکنید.
5. در rationale، decisive field، simpler alternative و failure/ownership boundary را بیاورید.
6. review_due و stop_or_pivot_trigger قابل‌اندازه‌گیری اضافه کنید.
7. placeholderهای template را پر و python run_checks.py evidence/decision_matrix.template.json را اجرا کنید.

در Independent pass، authoritative non-reconstructable cache، workflow چندروزه با human checkpoint، حذف recovery requirement، evidence ناقص و owner گمشده را آزمایش کنید. هر fail باید شما را به یک field visible برگرداند؛ answer key مخفی وجود ندارد.

برای transfer از reconciliation fixture استفاده کنید. cache pressure معنادار ندارد، ولی process چندروزه، human checkpoint، external callهای retryable و history/recovery requirement دارد. هر سه row را دوباره محاسبه کنید. Redis/Valkey می‌تواند NOT_NOW بماند و Temporal به PILOT برود؛ فقط evidence جدید این تغییر را justify می‌کند.

Evidence package قابل‌قبول چه دارد؟

Reviewer باید بدون hidden reasoning نتیجه را بازسازی کند. برای CACHE، authority، reconstructability، read pattern، latency target/measurement، TTL، eviction tolerance، freshness، alternative، owner، cost و failure دیده می‌شود. برای EPHEMERAL_COORDINATION، primitive مشترک، atomicity، TTL/lease، partition/fallback، durability boundary، trigger و correctness consequence روشن است. برای DURABLE_WORKFLOW، duration، checkpoint، retry، recovery، replay/history، external effect، runner ساده‌تر، owner، migration cost و failure surface ثبت شده است.

authority_refs نقش sourceها را جدا می‌کند. REDISUSE factهای محدود use caseهای Redis را پشتیبانی می‌کند؛ VALKEYINTRO data structure و optionهایی مثل TTL، eviction، replication و persistence را؛ TEMPORAL مرز durable execution/recovery را. AWR-002-K4 gate طراحی MAKNOW را می‌دهد. [REDISUSE] [VALKEYINTRO] [TEMPORAL]

checker exact fixture binding، state vocabulary، پیش‌شرط positive state، NOT_NOW معتبر، basis stateهای غیرموفق، ownership، cost/failure evidence و authority trace را می‌سنجد. expected-decision table مخفی ندارد. AI می‌تواند supplied evidence را مرتب و comparison deterministic را اجرا کند، اما latency، owner، recovery need، adoption approval یا migration success را نمی‌سازد.

Assessment و Transfer

AWR-002-F1: boundary مالکیت درس و یک non-goal مجاور را بیان کنید. پاسخ باید awareness مربوط به cache/coordination/durable workflow را از deployment و درس‌های مجاور Kubernetes/Kafka و search/API جدا کند.

AWR-002-F2: mutation تبدیل نسخه‌ی cache قابل‌بازسازی به record authoritative غیرقابل‌بازسازی را diagnose کنید. fieldهای invalid، consequence و minimal repair را بنویسید.

AWR-002-F3: reconciliation transfer را از نو محاسبه کنید و جواب baseline را کپی نکنید.

AWR-002-S1: boundary و یک non-goal را با بیان خودتان توضیح دهید.

AWR-002-S2: State/Cache/Workflow Technology Fit Matrix v1 سه‌ردیفه را از baseline synthetic بسازید.

AWR-002-S3: authoritative-cache mutation را تحلیل کنید. جمله‌ی «persistence را روشن می‌کنیم» کافی نیست؛ authority، loss، eviction، backup و recovery reasoning باید restore شود.

AWR-002-S4: سیستم دوم cache pressure ندارد ولی financial reconciliation چندروزه، human checkpoint، external call retryable و recoverable history می‌خواهد. همه‌ی rowها را recompute کنید و توضیح دهید چرا Temporal شاید PILOT شود اما Redis/Valkey NOT_NOW بماند.

Transfer فقط وقتی پاس است که decision جدید به evidence جدید trace شود. «Temporal برای workflow ساخته شده» capability را بیان می‌کند؛ local problem fit، alternative، owner، cost و stop condition را کامل نمی‌کند.

منابع و Freshness Boundary

REDISUSE — مستندات رسمی Redis درباره use caseها؛ fact محدود الگوهایی مانند rate limiting، session storage، cache-aside، queue، Pub/Sub و stream را پشتیبانی می‌کند. نیاز این application به Redis را اثبات نمی‌کند. [REDISUSE]

VALKEYINTRO — معرفی رسمی Valkey؛ fact محدود open-source in-memory data-structure store با کاربرد database، cache، message broker و streaming و optionهای replication، TTL، eviction و persistence را پشتیبانی می‌کند. semantic fit یا آمادگی عملیاتی این پروژه را ثابت نمی‌کند. [VALKEYINTRO]

TEMPORAL — مستندات رسمی Temporal؛ claim محدود durable execution با هدف ادامه‌ی workflow پس از crash، network failure یا infrastructure outage را پشتیبانی می‌کند. نیاز یک asynchronous job خاص به Temporal را اثبات نمی‌کند. [TEMPORAL]

این منابع رسمی در 2026-09-12 دوباره بررسی شدند و هیچ تغییر مادی‌ای نیازمند گسترش یا بازنویسی claim boundary قفل‌شده نبود. review بعدی همچنان 2026-12-02 است، یا زودتر اگر semantics platformهای cited تغییر مادی کند. external documentation فقط FACT capability است؛ threshold، decision label، ownership requirement و adoption gate در اختیار MAKNOW DESIGN می‌ماند.