{
  "title": "انتخاب Go برای Core",
  "slug": "team/platform/core/ADR/ADR-Core-001",
  "url": "/docs/team/platform/core/ADR/ADR-Core-001",
  "frontmatter": {
    "layout": "doc",
    "title": "انتخاب Go برای Core",
    "description": "مستند تصمیم معماری — بررسی دلایل انتخاب زبان Go برای پیاده‌سازی سرویس Core",
    "version": "1.0.0",
    "status": "APPROVED",
    "author": "xoxxel",
    "owner": "xoxxel",
    "created_at": "2026-06-11",
    "updated_at": "2026-06-13",
    "tags": "",
    "reviewers": ""
  },
  "sections": [
    {
      "level": 1,
      "heading": "انتخاب Go برای Core",
      "content": "**Choosing Go for Core**\n\n> **ADR-Core-001**\n\n---"
    },
    {
      "level": 2,
      "heading": "وضعیت",
      "content": "**Status**\n\n✅ **تایید شده (APPROVED)**\n\n---"
    },
    {
      "level": 2,
      "heading": "تاریخ",
      "content": "**Date**\n\n2026-06-11\n\n---"
    },
    {
      "level": 2,
      "heading": "زمینه",
      "content": "**Context**\n\nسرویس Core بخش زیرساختی و مرکزی پلتفرم NONS هستش.\nمسئولیت‌های اون شامل دریافت و اعتبارسنجی فنی رویدادها، ثبت لاگ‌های حسابرسی (Audit Logs)، پایش وضعیت سلامت سرویس‌ها و مدیریت Service Registry می‌شه.\n\nچون Core در مسیر عبور تمام رویدادهای سیستم توی NATS قرار داره، نیازمندی‌های فنی مهمی براش داریم:\n\n- **Throughput بالا:** باید بتونه حجم زیادی از رویدادها رو به طور همزمان پردازش کنه.\n- **Latency پایین:** نباید تاخیری در انتقال و بررسی رویدادها ایجاد کنه.\n- **پایداری طولانی‌مدت:** یه بار ساخته می‌شه و نباید مدام تغییر کنه.\n- **مصرف منابع پایین:** باید در کنار بقیه سرویس‌ها با حداقل پردازنده و رم کار کنه.\n\n---"
    },
    {
      "level": 2,
      "heading": "گزینه‌های بررسی‌شده",
      "content": "**Alternatives Considered**"
    },
    {
      "level": 3,
      "heading": "گزینه ۱: Node.js/NestJS",
      "content": "**Option 1: Node.js/NestJS**\n\n**دلیل بررسی:** بقیه سرویس‌های پلتفرم با NestJS نوشته می‌شن. اگه از یه ابزار یکسان استفاده می‌کردیم، هزینه یادگیری تیم کمتر می‌شد.\n\n**مشکلات:**\n\n- Node.js به صورت تک‌رشته‌ای (Single-thread) کار می‌کنه و برای کارهای همزمان به Event Loop وابسته هستش که توی بارهای کاری زیاد ممکنه گلوگاه (Bottleneck) بشه.\n- مصرف رم بالاتری نسبت به Go داره.\n- فریمورک NestJS برای یه سرویس زیرساختی سبک، سنگینه و Overhead اضافی ایجاد می‌کنه.\n\n**نتیجه:** رد شد."
    },
    {
      "level": 3,
      "heading": "گزینه ۲: Python",
      "content": "**Option 2: Python**\n\n**دلیل بررسی:** سرویس chat-service با پایتون نوشته می‌شه و تیم باهاش آشنایی داره.\n\n**مشکلات:**\n\n- وجود GIL (Global Interpreter Lock) توی پایتون جلوی پردازش‌های موازی واقعی رو می‌گیره.\n- مصرف منابعش واسه یه سرویس همیشه‌روشنِ زیرساختی بالا هستش.\n\n**نتیجه:** رد شد."
    },
    {
      "level": 3,
      "heading": "گزینه ۳: Go",
      "content": "**Option 3: Go**\n\n**دلیل بررسی:** زبان Go دقیقاً واسه نوشتن همین مدل سرویس‌های شبکه‌ای با کارایی بالا طراحی شده.\n\n**نتیجه:** ✅ پذیرفته شد.\n\n---"
    },
    {
      "level": 2,
      "heading": "دلایل انتخاب Go",
      "content": "**Reasons for Choosing Go**"
    },
    {
      "level": 3,
      "heading": "۱. Goroutines برای همزمانی واقعی",
      "content": "**Goroutines for Real Concurrency**\n\nزبان Go از Goroutine استفاده می‌کنه که بسیار سبک‌تر از Threadهای سیستم‌عامل یا Event Loop تک‌رشته‌ای هستن. هر اشتراک در NATS رو می‌شه توی یه Goroutine مستقل اجرا کرد تا هزاران پیام بدون مسدود شدن پردازش بشن.\n\n```go\n// هر رویداد در goroutine مستقل پردازش می‌شود\nnc.Subscribe(\"events.>\", func(msg *nats.Msg) {\n    go func() {\n        router.Handle(msg)\n    }()\n})\n```"
    },
    {
      "level": 3,
      "heading": "۲. مصرف حافظه پایین",
      "content": "**Low Memory Consumption**\n\nیه سرویس Go در حالت بیکاری (Idle) معمولاً کمتر از ۲۰ مگابایت رم مصرف می‌کنه، در حالی که معادل اون توی Node.js به راحتی بالای ۱۵۰ مگابایت رم می‌خواد. چون Core یه سرویس همیشه‌روشن هستش، این تفاوت در درازمدت خیلی به چشم میاد."
    },
    {
      "level": 3,
      "heading": "۳. کامپایل ایستا و فایل باینری مستقل",
      "content": "**Static Compilation & Independent Binary**\n\nزبان Go یه فایل باینری مستقل تولید می‌کنه که نیاز به هیچ Runtime یا مفسری نداره.\n\n```dockerfile"
    },
    {
      "level": 1,
      "heading": "Dockerfile نهایی Core",
      "content": "FROM scratch\nCOPY core /core\nENTRYPOINT [\"/core\"]\n```\n\nبا این کار حجم Image نهایی می‌تونه زیر ۲۰ مگابایت باشه که به استقرار سریع‌تر، امنیت بیشتر و استقرار روان‌تر از طریق چارت‌های Helm (D15) بر روی کلاستر K3s/K3d (D13) کمک شایانی می‌کند."
    },
    {
      "level": 3,
      "heading": "۴. استقلال فنی از بقیه سرویس‌ها",
      "content": "**Technical Independence**\n\nاینکه Core با Go نوشته بشه و بقیه سرویس‌ها با Node.js، یه مزیت حساب می‌شه. ارتباط اون‌ها از طریق NATS و در قالب پروتکل هستش و وابستگی به زبان هم ندارن."
    },
    {
      "level": 3,
      "heading": "۵. پایداری بلندمدت",
      "content": "**Long-Term Stability**\n\nزبان Go تعهد خیلی قوی روی سازگاری با نسخه‌های قبلی (Backward Compatibility) داره. Core قراره یه بار نوشته بشه و سال‌ها بدون تغییر اجرا بشه و Go بهترین گزینه واسه این کاره.\n\n---"
    },
    {
      "level": 2,
      "heading": "آنچه این تصمیم تغییر نمی‌دهد",
      "content": "**Scope Boundaries**\n\n- سرویس‌های بیزنسی همچنان با Node.js/NestJS نوشته می‌شن.\n- سرویس چت همچنان با Python توسعه داده می‌شه.\n- سرویس Core هیچ منطق کسب‌وکاری نداره و این تصمیم فقط مربوط به تکنولوژی خودِ Core هستش.\n\n---"
    },
    {
      "level": 2,
      "heading": "پیامدها",
      "content": "**Consequences**"
    },
    {
      "level": 3,
      "heading": "پیامدهای مثبت",
      "content": "**Positive Consequences**\n\n- کارایی و Throughput فوق‌العاده بالا برای پردازش رویدادها.\n- مصرف بسیار پایین منابع سرور.\n- فایل باینری سبک و مستقل.\n- تفکیک کامل لایه پلتفرم از لایه محصول."
    },
    {
      "level": 3,
      "heading": "پیامدهای منفی",
      "content": "**Negative Consequences**\n\n- تیم بک‌اند باید با زبان Go آشنا بشن تا بتونن Core رو نگهداری کنن.\n- وجود دو زبان مختلف در کل پروژه، هزینه مدیریت رو یه مقدار بالا می‌بره.\n\n---"
    },
    {
      "level": 2,
      "heading": "نتیجه",
      "content": "**Conclusion**\n\nزبان Go برای پیاده‌سازی سرویس Core انتخاب شد. این تصمیم بر اساس نیازهای فنیِ این لایه (همزمانی بالا، تاخیر کم و پایداری) گرفته شده، نه بر اساس ترجیحات شخصی اعضای تیم."
    }
  ]
}