معماری اجرای دواپس و عملیات پروداکشن
صف‌های job غیرهمزمان، ایزوله‌سازی workerها، حلقه بازخورد تله‌متری، استقرار Docker روی زیرساخت self-hosted و عملیات پایدار پروداکشن
پردازش‌های پس‌زمینه و صف‌های غیرهمزمان
workerهای Redis/BullMQ، سیاست retry، مرز DLQ و پاسخ سریع HTTP
سیستم پروداکشن نباید هر عملیات سنگین را داخل مسیر request-response تمام کند. کارهای CPU-heavy، ارسال پیام‌های انبوه، ساخت گزارش، fan-out وب‌هوک‌ها، پردازش media، jobهای زمان‌بندی‌شده و همگام‌سازی با سرویس‌های بیرونی اگر روی event loop اصلی اجرا شوند، latency کاربر را بالا می‌برند و API را در ترافیک burst غیرقابل اعتماد می‌کنند. بک‌اند بالغ، پذیرش درخواست را از اجرای واقعی جدا می‌کند: کاربر سریع پاسخ می‌گیرد، اما عملیات سنگین وارد مسیری می‌شود که برای تاخیر، شکست و اجرای مجدد طراحی شده است.
مدل امن‌تر، ساختن یک مرز اجرایی queue-backed است: لایه HTTP intent را اعتبارسنجی می‌کند، job را ثبت می‌کند، پاسخ `202 Accepted` برمی‌گرداند و workerهای جداگانه task را با retry policy، idempotency key، backoff، rate limit و dead-letter handling پردازش می‌کنند. Redis/BullMQ بین ترافیک محصول و اجرای سنگین یک buffer عملیاتی می‌سازد. نتیجه این است که latency API قابل پیش‌بینی می‌ماند، اثر جانبی تکراری تولید نمی‌شود، شکست‌ها مسیر بازیابی و بررسی دارند و workerها مستقل از web process مقیاس می‌گیرند.
سنجش و تحلیل بلادرنگ تله‌متری و لاگ‌ها
مشاهده‌پذیری کامل سلامت پلتفرم با Pino و صادرکننده‌های تله‌متری
سیستمی که دیده نشود، در پروداکشن قابل اداره کردن نیست. مشاهده‌پذیری فقط داشبورد تزئینی نیست؛ حلقه بازخوردی است که رفتار واقعی سیستم را به تصمیم مهندسی تبدیل می‌کند. هر request مهم باید correlation ID، لاگ JSON ساختاریافته، هیستوگرام latency، نرخ خطا، فشار connection pool دیتابیس و متریک‌های منابع داشته باشد تا مشخص شود چه اتفاقی افتاده، کجا اتفاق افتاده و کدام مرز معماری زیر فشار است.
مدل عملیاتی این بخش بر پایه لاگ‌گیری سریع با Pino، صادرکننده‌های متریک برای CPU/RAM/connection pool و آستانه‌های هشدار متصل به سیگنال‌های SLO مثل p95 latency و درصد خطا است. نکته مهم correlation است: جهش ترافیک باید از route به log line، از log line to metric و از metric به واکنش عملیاتی قابل ردیابی باشد؛ مثل افزایش worker، تنظیم pool، یا ایزوله کردن سرویس خطادار.
استقرار کانتینری روی سرورهای مجازی اختصاصی (VPS)
imageهای Docker، reverse proxy، SSL خودکار، volume، backup و release قابل rollback
self-hosting فقط انتقال فایل به یک سرور ارزان‌تر نیست؛ یعنی مالکیت قرارداد runtime. استقرار قابل اعتماد روی VPS به imageهای Docker قابل تکرار، مرزهای روشن env، شبکه قابل پیش‌بینی، reverse proxy، صدور خودکار SSL، volumeهای پایدار، نظم backup و مسیر rollback نیاز دارد؛ مسیری که به حافظه اپراتور یا تاریخچه دستورات SSH وابسته نباشد.
معماری عملیاتی این بخش، اپلیکیشن، workerها، cache و سرویس‌های نزدیک به دیتابیس را به واحدهای کانتینری تبدیل می‌کند. ابزارهایی مثل Docker Compose و Coolify روی VPS خام لینوکسی، build، تزریق env، health check، مسیردهی دامنه و restart policy را هماهنگ می‌کنند. Traefik یا Nginx ترافیک و TLS را مدیریت می‌کند و imageهای نسخه‌دار همراه با volumeهای کنترل‌شده، استقرار را قابل تکرار، قابل مشاهده و قابل بازیابی نگه می‌دارند.
بازیابی خودکار و پایداری کانتینرها (Auto-Healing)
health probe، restart policy، reroute ترافیک و محدود کردن اثر crash
پایداری پروداکشن به این معنا نیست که هیچ crashای رخ ندهد؛ یعنی سیستم بتواند خرابی را سریع تشخیص دهد، آن را ایزوله کند و قبل از تبدیل شدن به قطعی طولانی، خودش را بازیابی کند. کانتینرها باید health endpoint معنادار داشته باشند، ناظر runtime باید بفهمد چه زمانی process دیگر امن نیست، و لایه proxy نباید ترافیک را به target خراب بفرستد.
قرارداد بازیابی از ترکیب `/api/healthz`، بررسی اتصال دیتابیس، guard مصرف حافظه، Docker restart policy، نظارت PM2/runtime و draining ترافیک ساخته می‌شود. وقتی کانتینر unhealthy می‌شود، سیستم باید آن را restart کند، مسیر ترافیک را اصلاح کند، لاگ‌ها را برای تشخیص نگه دارد و blast radius خرابی را کوچک نگه دارد. Auto-Healing فقط restart کور نیست؛ انضباط عملیاتی است که داخل runtime کدنویسی شده است.
آماده ورود به فاز ۶: ریاضیات دقیق و دفتر کل مالی هستید؟
در فاز نهایی به ریاضیات پایداری داده‌ها، مهندسی هسته مالی، محاسبات عدد صحیح و الگوی دفتر کل فقط-افزودنی می‌رسیم؛ جایی که داده دیگر فقط ذخیره نمی‌شود، بلکه به صورت ریاضی قابل اثبات است.