💥 مهاجرت یک‌باره (Big Bang Migration): بازسازی کامل از Node.js به Go

مقدمه

گاهی وقت‌ها نمی‌شه با وصله‌پینه و ریفکتورهای کوچک آینده‌ی پروژه رو ساخت.
به کد نگاه می‌کنی، پر از تودرتوهای قدیمی و منطق‌های سنگینه، و می‌گی:

"دیگه این درست‌شدنی نیست. باید از صفر بسازیمش."

اینجاست که مهاجرت یک‌باره یا Big Bang Migration مطرح می‌شه.
حرکتی جسورانه که در اون، سیستم قدیمی به‌طور کامل با نسخه‌ی جدید جایگزین می‌شه — در یک لانچ واحد.

ریسکیه؟ قطعاً.
ولی گاهی تنها راه واقعیه.

در این مقاله تجربه‌ی واقعی ما از بازنویسی بک‌اند از Node.js به Go رو توضیح می‌دم؛ مسیری پرچالش اما موفق.

⚡ مهاجرت Big Bang چیست؟

در این مدل، سیستم فعلی رو یک‌جا و کامل با سیستم جدید جایگزین می‌کنی.
هیچ اجرای همزمانی بین قدیم و جدید وجود نداره.
همه‌چیز طراحی، پیاده‌سازی و تست می‌شه — و در یک لحظه سوئیچ می‌کنی.

مثل خراب‌کردن یه خونه و ساخت دوباره‌ی اون روی همون زمین.

🧠 چرا ما Big Bang رو انتخاب کردیم؟

بک‌اند ما با Node.js شروع شده بود، اما طی ۴ سال به هیولایی ۲۰۰ هزار خطی تبدیل شد:

• حجم زیاد منطق CPU-bound (آنالیز، پردازش ویدیو)

• مشکلات مقیاس‌پذیری در ترافیک بالا

• لیک حافظه و باگ‌های async

• عملکرد ناپایدار در بار زیاد

بهینه‌سازی‌ها جواب نمی‌دادن.
به Go نگاه کردیم — زبان سریع‌تر، همزمانی ذاتی (goroutine) و مدیریت حافظه‌ی بهتر.

اما مهاجرت تدریجی ممکن نبود؛ دو محیط کاملاً متفاوت بودن.
پس تصمیم گرفتیم همه‌چیز رو از اول بسازیم.

🧭 برنامه‌ریزی مهاجرت

کلید موفقیت در Big Bang، برنامه‌ریزی دقیقه.

1. توقف توسعه فیچر جدید

برای دو ماه هیچ فیچر تازه‌ای اضافه نکردیم تا سیستم فعلی پایدار بمونه.

2. مستندسازی کامل

تمام APIها، مدل‌های داده، و وظایف پس‌زمینه رو مستند کردیم تا قرارداد رفتاری نسخه‌ی جدید مشخص باشه.

3. همسان‌سازی لایه‌ی API

در نسخه‌ی Go، تمام endpointها دقیقاً مثل Node طراحی شدن تا فرانت‌اند یا اپ موبایل نیازی به تغییر نداشته باشه.

4. تست در محیط جدا

سرویس Go رو در محیط staging بالا آوردیم، با دیتابیس کپی‌شده از production.
هر روز با داده‌ی واقعی تست فشار (load test) می‌گرفتیم.

5. شبیه‌سازی ترافیک

قبل از لانچ نهایی، یه هفته درخواست‌های واقعی کاربرها رو shadow کردیم تا رفتار سیستم رو در شرایط واقعی بسنجیم.

6. روز مهاجرت

در ساعت ۲ بامداد، با تغییر تنظیمات Load Balancer، ترافیک از Node به Go منتقل شد:

service backend set-target go-app

در عرض ۳۰ ثانیه همه‌ی درخواست‌ها به سرویس جدید رسید.

7. طرح بازگشت (Rollback)

اگر مشکلی پیش می‌اومد، با یک تغییر ساده می‌تونستیم ترافیک رو به Node برگردونیم — بدون تغییر در دیتابیس.

⚙️ نکات فنی

• استفاده از Go Fiber به‌عنوان وب‌فریم‌ورک سریع و سبک

• GORM برای ORM با PostgreSQL

• اشتراک JWT tokens با فرانت‌اند (بدون تغییر در auth)

• پردازش وظایف با goroutine و Redis Stream

• مانیتورینگ با Prometheus + Grafana

نمونه‌ای ساده از ساختار Go:

app := fiber.New()

app.Get("/api/users/:id", getUserHandler)
app.Post("/api/upload", uploadHandler)
app.Post("/api/aggregate", aggregateHandler)

log.Fatal(app.Listen(":8080"))

همه‌ی کارهایی که قبلاً چند پروسه‌ی Node لازم داشت، حالا با goroutineها انجام می‌شد.

⏱ کل فرآیند ۳ ماه توسعه و فقط یک شب انتشار طول کشید.
بدون هیچ قطعی جدی — فقط یک بازه‌ی کوتاه فقط‌خواندنی هنگام سینک دیتابیس.

⚠️ درس‌های آموخته‌شده

۱. Big Bang یعنی ریسک بزرگ.
یک باگ می‌تونه کل سیستم رو از کار بندازه. تست و مانیتورینگ حیاتی‌ان.

۲. محیط موازی (Shadow Testing) نجات‌بخشه.
قبل از لانچ، ترافیک واقعی رو به‌صورت مخفی به Go فرستادیم تا باگ‌ها زودتر شناسایی شن.

۳. ارتباط تیمی حیاتی‌ه.
از dev تا پشتیبانی، همه از برنامه‌ی مهاجرت خبر داشتن — هیچ شوکی در سازمان پیش نیومد.

۴. قراردادهای API رو ثابت نگه دار.
بازنویسی به معنی تغییر رفتار نیست. تطابق APIها باعث شد کاربران هیچ تغییری حس نکنن.

🧭 چه زمانی Big Bang انتخاب مناسبه؟

مناسب زمانی که...نامناسب زمانی که...سیستم فعلی غیرقابل نگه‌داریههنوز می‌شه بخش‌به‌بخش ریفکتور کرددو محیط فنی قابل همزیستی نیستنمی‌تونی قدیم و جدید رو کنار هم اجرا کنیتست پوشش کامل داریتست و staging نداریمی‌تونی کمی downtime بپذیریسرویس ۲۴/۷ فعاله

🏁 جمع‌بندی

مهاجرت یک‌باره شرط‌بندی بزرگیه — ولی اگه درست برنامه‌ریزی بشه، می‌تونه همه‌چیز رو متحول کنه.
ما با این بازنویسی از Node به Go تونستیم:

• سرعت سیستم رو دو برابر کنیم

• مصرف منابع رو نصف کنیم

• و بک‌اند تمیز و مقیاس‌پذیری بسازیم

گاهی برای ساخت آینده، باید گذشته رو کامل کنار بذاری.