اگر در حال اینک هستید که برای هر خطای سیستمی در یک سامانه مالی، ساعتها زمان صرف بازسازی وضعیت (State) دادهها کنید، باید بدانید که دوران لولهکشی دستیِ دادهها به پایان رسیده است. امروز، بقای یک فرآیند پس از مرگ سرور، دیگر یک شاهکار مهندسی نیست، بلکه یک دستهبندی محصولی است. این تغییر رویکرد در جریان یک بررسی عمیق در مورد تکامل سیستمهای توزیعشده در تاریخ ۴ اوت ۲۰۲۶ آشکار شد و سیگنالی بود مبنی بر اینکه سیستمهای مالی در حال فاصله گرفتن از حلقههای تکرار (Retry Loops) دستساز و حرکت به سوی پایداری قابلنصب (Installable Durability) هستند.
تصور کنید در یک فرآیند سه مرحلهای در یک شرکت فینتک هستید: مرحله اول مشتری را تأیید میکند، مرحله دوم یک رکورد داخلی میسازد و مرحله سوم پول را منتقل کرده، اشتراکی را تغییر میدهد یا یک درخواست بازگشتناپذیر را به یک شریک تجاری ارسال میکند. اگر سرور دقیقاً بعد از انتقال پول اما قبل از پایان فرآیند کرش کند — مثلاً به دلیل کشته شدن کانتینر، اجرای یک رولبک در استقرار (Deploy)، ناپدید شدن میزبان (Host) یا ریاستارت شدن Worker در نیمه راه — یک شروع مجدد ساده از مرحله اول ممکن است باعث شود پول به اشتباه دو بار منتقل شود.
از سوی دیگر، اگر برای جلوگیری از تکرار، مراحل زیادی را نادیده بگیرید، ممکن است مشتری را در وضعیتی «نیمهفعال» رها کنید. این همان شکل بنیادین بسیاری از کارهای فینتکی است: از بازگشایی حساب و فعالسازی اشتراک گرفته تا پرداخت تسهیلات اعتباری، تسویه بازپرداختها، بهروزرسانیهای KYC، جاروبهای زمانبندیشده (Scheduled Sweeps) و ثبت در دفترکل (Ledger Posting). اینها تراکنشهای ساده پایگاهداده نیستند، بلکه داستانهای کوچک تجاری هستند که در لباس فراخوانی تابع (Function Call) ظاهر شدهاند.
بهطور سنتی، مهندسان این مشکل را با یک نظم سختگیرانه در معماریهای رویداد-محور (Event-driven) با استفاده از Kafka و ماشینهای وضعیت (State Machines) پیچیده حل میکردند. این سبک در محیطهایی به اندازه یک بانک معنا پیدا میکند، اما بخش خستهکننده این کار هرگز صرفاً «ارسال یک رویداد» نبود. کار واقعی این بود که تصمیم بگیرند هر مرحله چه معنایی دارد، کدام پیام منبع حقیقت (Source of Truth) است، چگونه تکرارها شناسایی شوند، چگونه مصرفکنندگان (Consumers) برای بازپخش (Replay) ایمن شوند و چگونه برای چیزی که از مرز سیستم عبور کرده، جبران (Compensate) شود.
این رویکرد دستی، یک مالیات عملیاتی سنگین ایجاد میکند. هر تیم باید بهطور مستقل همان داربستهای تکراری را بازسازی کند — کلیدهای یکتا (Idempotency Keys)، جداول Outbox، تاپیکهای تکرار (Retry Topics)، کارهای تطبیق (Reconciliation Jobs)، مسیرهای بازرسی (Audit Trails)، داشبوردها، هشدارها و دفترچههای راهنما (Runbooks) — فقط برای اینکه مطمئن شوند یک Worker میتواند پس از یک کرش، کار را از سر بگیرد. کار واقعی انتشار یک رویداد نیست؛ بلکه تصمیمگیری در مورد اینکه کدام پیام منبع حقیقت است. شما نمیتوانید با جملهی «صف ما در نهایت سازگار است» (Eventually Consistent) از کنار جابهجایی پول رد شوید و سپس به ناهار بروید.
ظهور چارچوبهای پایدار
چارچوبهای جدید با بستهبندی قابلیت اطمینان به عنوان یک کتابخانه یا سرویس، این پیشفرض را تغییر میدهند. آنها «بهخاطر سپردن مرحله سوم پس از کرش Worker» را از یک کار لولهکشی دستی به یک ویژگی محصول تبدیل کردهاند.
Temporal این موضوع را با ذخیره تاریخچه رویدادهای پایدار برای هر اجرای گردش کار مدیریت میکند.
- سازوکار: وقتی یک Worker کرش میکند یا ریاستارت میشود، کد گردش کار میتواند از روی تاریخچه بازپخش (Replay) شود.
- تضمین: فعالیتهای تکمیلشده صرفاً تکرار نمیشوند، زیرا سرویس سوابق دقیقی از آنچه اتفاق افتاده است نگه میدارد.
- مدل هزینه: Temporal Cloud یک مدل قیمتگذاری بر اساس مصرف (Consumption-based) ارائه میدهد که عمدتاً بر اساس اکشنها و ذخیرهسازی است و حداقل طرح آن ۱۰۰ دلار در ماه ذکر شده است.
DBOS رویکرد متفاوتی با DBOS Transact دارد؛ یک کتابخانه متنباز که درون اپلیکیشن اجرا میشود.
- سازوکار: طبق مستندات DBOS، ابزار Transact از پایگاهداده Postgres موجود شما برای ذخیره و بازیابی وضعیت گردش کار و تاریخچه اجرا استفاده میکند.
- ابزارهای عملیاتی: این پلتفرم سرویس DBOS Conductor را ارائه میدهد که یک سطح پولی (Paid Tier) برای فراهم کردن نظارت (Monitoring)، ابزارهای بازیابی، نسخهبندی، هشدارها و پشتیبانی است.
- قیمتگذاری: مدلهای پولی آنها برای طرحهای Pro و Teams بر اساس میزان استفاده از نقاط بازرسی (Checkpoint) قیمتگذاری شدهاند.
هر دو پلتفرم در واقع توانایی بقای یک شغل چندمرحلهای در برابر مرگ فرآیند را محصولسازی کردهاند و نیاز به کارهای زیرساختی سفارشی را حذف کردهاند.
تلهی طراحی
تفاوت حیاتی بین سیستمی که «چه اتفاقی افتاد» را به خاطر میسپارد و سیستمی که میداند «چه اتفاقی باید بیفتد» وجود دارد. یک چارچوب میتواند گردش کار را قابل بازگشت کند، تکمیل مراحل را ثبت نماید و تاریخچه را به جای دفن کردن در Logها، قابل مشاهده کند، اما این چارچوب دارای منطق تجاری (Business Logic) نیست.
انتخابهای طراحی همچنان انسانمحور هستند. یک چارچوب نمیتواند به توسعهدهنده بگوید:
- آیا شارژ حساب مشتری باید قبل یا بعد از فعالسازی اشتراک باشد؟
- آیا یک فعالسازی شکستخورده باید باعث بازپرداخت (Refund)، یک تکرار مجدد، یک بازبینی دستی (Manual Review) یا یک دوره اهدای فرصت (Grace Period) شود؟
- آیا یک API شریک تجاری واقعاً تکرارناپذیر (Idempotent) است، صرفاً به این دلیل که یک کلید Idempotency را میپذیرد؟
- آیا یک «مرحله» تعریف شده، یک اقدام تجاری است یا سه اقدام تجاری که در لباس یک مرحله ظاهر شدهاند؟
در یک شرکت فینتک در منطقه خلیج فارس، این موضوع در «جاروبهای زمانبندیشده» (Scheduled Sweeps) تجلی مییابد. پیچیدگی این نیست که یک تایمر فعال شده است، بلکه سیستم باید بداند کدام حسابها مورد بررسی قرار گرفتهاند، کدامها نادیده گرفته شدهاند و کدام تماسهای خارجی موفق بودهاند. در حالی که ثبت یک مرحله تکمیلشده در Postgres بهتر از یک خط Log و یک دعا است، اما کار طراحی همچنان باقی است.
مرز تکرارناپذیری (Idempotency)
تضمینهای داخلی قوی هستند اما لبههای سیستم همچنان آشفتهاند. در داخل مرز چارچوب، شما تضمینهای محکمی برای نتایج فعالیتها و تکرارهای کنترلشده دارید. اما در مرز خارجی، واقعیت هرجومرج است.
ارائهدهندگان پرداخت، شرکای بانکی، سیستمهای ایمیل، تأییدکنندگان هویت و پردازشگرهای کارت، همگی ایدههای متفاوتی درباره درخواستهای تکراری دارند. برخی از تکرارناپذیری (Idempotency) به خوبی پشتیبانی میکنند، در حالی که برخی دیگر فقط در مستندات خود یا تا زمانی که یک Timeout بین اثر جانبی (Side effect) آنها و پاسخ شما رخ دهد، از آن پشتیبانی میکنند.
مهندسان همچنان باید موارد زیر را مدیریت کنند:
- شناسههای درخواست پایدار (Stable Request Identifiers)
- ارجاعات ارائهدهنده (Provider References)
- فرآیندهای تطبیق (Reconciliation)
اجرای پایدار نقاط نشت این منطق را کاهش میدهد، اما قوانین سیستمهای توزیعشده را لغو نمیکند. شما هنوز باید تشخیص دهید که یک Timeout به معنای «هیچ اتفاقی نیفتاد»، «اتفاقی افتاد اما شما آن را ندیدید» یا «بعداً بررسی کنید» است.
الگوی گستردهتر زیرساختی
این چرخش از یک الگوی تکرارشونده در مهندسی نرمافزار پیروی میکند. ویژگیهای قابلیت اطمینان ابتدا به عنوان یک «صنعت دستی»-Craft توسط تیمهای نخبه مدیریت میشوند که چاره دیگری ندارند. در نهایت، تعداد کافی از تیمها با همان درد مواجه میشوند و آن ویژگی به یک «محصول» تبدیل میشود.
چندین دسته این مسیر را طی کردهاند:
- Observability (مشاهدهپذیری)
- Feature flags (پرچمهای ویژگی)
- Secrets management (مدیریت اسرار)
- CI/CD (یکپارچهسازی و استقرار مداوم)
- Policy-as-code (سیاست به عنوان کد)
اکنون اجرای پایدار (Durable Execution) همین مسیر را طی میکند. این تمرکز بر تداوم و پایداری در لایههای زیرساختی، شباهت زیادی به تغییر رویکرد در استراتژیهای فروش دارد؛ جایی که تداوم پیگیری و پایداری در ارتباط برتری بیشتری نسبت به حجم انبوه پیامها ایجاد میکند. با انتقال ویژگیهای خستهکننده لایه کنترل به یک فروشنده یا چارچوب، زمان مهندسی به سطوح بالاتر منتقل میشود. تیمها دیگر نمیپرسند «چگونه جدول Retry بسازیم؟» یا «چگونه پس از کرش بازگردیم؟»، بلکه میپرسند «کجا مرزی است که تکرار به جبران (Compensation) تبدیل میشود؟» و «بازگشت برای این مشتری چه معنایی دارد؟»
ارزش دیگر در اثبات اینکه یک Worker میتواند از ریاستارت جان سالم به در ببرد نیست. در عوض، تمرکز اکنون بر این است که تصمیم بگیرند کدام گردشهای کاری استحقاق پایداری دارند، کدام مراحل از نقطه نظر تجاری اتمیک (Atomic) هستند و چه کسی مالک نهایی نتیجه برای مشتری است.
گام بعدی شما
- اگر سیستمهای توزیعشده پیچیدهای دارید، بررسی کنید که آیا منطق بازیابی شما در لایهی کد است یا در لایهی زیرساخت؛ در صورت اول، مهاجرت به Temporal یا DBOS را ارزیابی کنید.
- در طراحی APIهای خارجی، روی پیادهسازی کلیدهای Idempotency متمرکز شوید تا وابستگی شما به لایهی بازیابی کاهش یابد.
- تفاوت بین «تکرار» (Retry) و «جبران» (Compensation) را در سناریوهای شکست سیستم خود مدلسازی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو