Go یا Rust یا Node.js؟ انتخاب بک‌اند با Benchmark و TCO

بدترین زمان برای انتخاب زبان بک‌اند، وقتی است که تیم با یک نمودار Benchmark عمومی هیجان‌زده شده است. عدد Request/second در یک «Hello World» نمی‌گوید سرویس شما با PostgreSQL، JSON، TLS، صف، Logging، خطای شبکه و توسعه‌دهنده‌ای که باید ساعت سه صبح Incident را رفع کند چه رفتاری خواهد داشت.

Go، Rust و Node.js هر سه می‌توانند بک‌اند Production بسازند؛ اما هیچ‌کدام «بهترین» نیستند مگر اینکه Workload، SLO، مهارت تیم، اکوسیستم، مدل استقرار و هزینه تغییر را تعریف کرده باشید. این راهنما یک مسابقه زبان نیست؛ چارچوبی است برای تصمیم قابل‌دفاع، Pilot هم‌سطح و Rollout قابل‌بازگشت—با ملاحظات تیم و زیرساخت ایران.

پیش از مقایسه: دقیقاً چه چیزی را انتخاب می‌کنیم؟

Go و Rust زبان‌های کامپایل‌شونده‌اند. Node.js زبان نیست؛ Runtime جاوااسکریپت است و پروژه Production اغلب JavaScript یا TypeScript را با Package ecosystem و Framework مشخص اجرا می‌کند. بنابراین مقایسه منصفانه باید «Stack قابل استقرار» باشد:

• Go + نسخه Toolchain + Router/DB driver + Build flags؛
• Rust + Edition/Toolchain + Async runtime + Web framework + Cargo profile؛
• Node.js + نسخه Runtime + JavaScript/TypeScript + Framework + Package manager.

حتی انتخاب Database driver، Serialization library، Connection pool و Logging می‌تواند از نام زبان اثر بیشتری بر نتیجه داشته باشد. Snapshot گزینه را تاریخ‌دار و Versionدار کنید.

Decision Contract: مسئله را قبل از ابزار بنویسید

یک تصمیم خوب با جمله «API سریع می‌خواهیم» شروع نمی‌شود. Contract نمونه:

Journey: جست‌وجوی کالا و ثبت سفارش
Traffic: baseline / peak / burst / growth
Workload: 80% I/O، 15% JSON/validation، 5% CPU-heavy
SLO: availability، p95/p99 latency، error budget
Data: consistency، transaction، payload، residency
Constraints: تیم، deadline، SDK، deploy target، budget
Failure: timeout، dependency outage، overload، rollback
Evidence: production-like benchmark + operability drill

Hard gate پیش از امتیازدهی

اگر گزینه‌ای Driver پشتیبانی‌شده برای فناوری حیاتی، Runtime مجاز روی Platform، توان استخدام/آموزش یا مسیر Patch امنیتی قابل‌قبول ندارد، با امتیاز Performance جبرانش نکنید. Hard gateها را اول اجرا کنید:

• SDK و Protocol موردنیاز؛
• پشتیبانی Database/Queue/Identity provider؛
• هدف استقرار، معماری CPU و محدودیت Container/Serverless؛
• Compliance، Cryptography یا کتابخانه Vendor؛
• مهارت On-call و حداقل Bus factor؛
• دسترسی پایدار به Registry، Toolchain و Artifact در ایران؛
• زمان تا اولین Release و ظرفیت آموزش.

Snapshot فنی Go، Rust و Node.js

Go: Toolchain منسجم و Concurrency در Runtime

Go به کد ماشین کامپایل می‌شود، Garbage collector دارد و Goroutineها را روی Threadهای سیستم‌عامل زمان‌بندی می‌کند. Standard library شبکه و HTTP آن برای بسیاری از سرویس‌ها نقطه شروع قوی است. Effective Go توضیح می‌دهد که Goroutine سبک است و Channel می‌تواند ارتباط/همگام‌سازی را مدل کند؛ همان منبع نیز هشدار می‌دهد این رویکرد نباید افراطی شود و گاهی Mutex مناسب‌تر است.

مزیت محتمل: Build/Deploy نسبتاً ساده، Convention زیاد و مسیر کوتاه برای سرویس شبکه. هزینه محتمل: خطاهای Runtime مانند nil dereference، Data race در کد اشتراکی، GC/Allocation و سادگی‌ای که اگر معماری ضعیف باشد خودکار نجات‌بخش نیست.

Rust: کنترل، Ownership و هزینه یادگیری/طراحی

Rust بدون Garbage collector عمومی، با Ownership و Borrowing بسیاری از خطاهای Memory safety را در Safe Rust به Compile-time می‌برد. کتاب رسمی Rust درباره Ownership توضیح می‌دهد چگونه این مدل بدون هزینه Runtime یک GC، تضمین‌های حافظه ایجاد می‌کند.

Rust برای CPU/Memory-sensitive component، Binary/Agent و سرویس‌هایی که کنترل تخصیص مهم است جذاب است. در عوض، طراحی Lifetime/Ownership، Generic/trait errorها، زمان Compile و انتخاب/مدیریت Async runtime می‌تواند هزینه توسعه و Onboarding را بالا ببرد. Safe Rust تمام امنیت وب را تضمین نمی‌کند؛ Injection، Authorization، SSRF و Business logic همچنان ممکن‌اند و unsafe/FFI مرز جدا دارد.

Node.js: Event Loop، اکوسیستم JavaScript و I/O

Node.js Callbackهای JavaScript را روی Event Loop اجرا می‌کند و برای بخشی از عملیات از Worker pool داخلی استفاده می‌کند. مستند رسمی Node.js درباره Block نکردن Event Loop می‌گوید وقتی کار هر Client کوچک بماند، Runtime می‌تواند Clientهای متعدد را خوب مدیریت کند؛ Callback یا Task سنگین هم Performance و هم مقاومت در برابر DoS را تضعیف می‌کند.

مزیت محتمل: تیم Full-stack، Iteration سریع، Package/SDK فراوان و تناسب با I/O-heavy orchestration. هزینه محتمل: CPU work روی Event Loop، Runtime type error در JavaScript، Dependency surface بزرگ، Memory/GC و نیاز به Discipline برای Async error/backpressure. TypeScript بخشی از خطاها را زودتر آشکار می‌کند، اما Validation مرز Runtime و امنیت Dependency را حذف نمی‌کند.

«Performance» یک عدد نیست

سریع‌ترین پاسخ میانگین، اگر صدک ۹۹ ناپایدار یا Error در Burst بالا باشد، ممکن است بدترین انتخاب محصول باشد. Metricها را براساس SLO انتخاب کنید.

CPU-bound و I/O-bound را تفکیک کنید

API که بیشتر زمان را منتظر Database/HTTP می‌ماند با Encoder ویدئو یک Workload نیست. Node.js می‌تواند I/O زیاد را با Event Loop مدیریت کند، ولی CPU طولانی باید تقسیم، به Worker/Process یا سرویس جدا منتقل شود. Go و Rust هم با Concurrency نامحدود سریع نمی‌شوند؛ Saturation، Queue و Downstream limit تعیین‌کننده‌اند.

Tail latency و Coordinated omission

Load generator باید زمان انتظار واقعی Client را ببیند و هنگام کندشدن سرور، نمونه‌های بد را حذف نکند. Open-loop و Closed-loop رفتار متفاوت دارند. Warm-up، JIT در Node، Cache، Connection pool، DNS/TLS و GC را در Method ثبت کنید. نتیجه بدون Method قابل‌تکرار، Evidence نیست.

Concurrency، Parallelism و Backpressure

Concurrency یعنی پیشرفت چند کار؛ Parallelism یعنی اجرای هم‌زمان روی چند Core. هیچ مدل Concurrency بدون Bound امن نیست. اگر ورودی سریع‌تر از خروجی باشد، Queue یا Memory رشد می‌کند و سرویس فرو می‌ریزد.

Go: Goroutine نامحدود نسازید

Goroutine ارزان‌تر از OS thread است، نه رایگان. Pool، Semaphore، Context cancellation، Deadline و Queue cap تعریف کنید.

sem := make(chan struct{}, maxConcurrent)
for job := range jobs {
    sem <- struct{}{} // backpressure
    go func(j Job) {
        defer func() { <-sem }()
        handle(j)
    }(job)
}

Race detector را در تست مرتبط اجرا کنید؛ مستند رسمی Go Data Race Detector دستور go test -race را شرح می‌دهد. نبود Report در تست محدود، اثبات نبود Race در تمام مسیرها نیست.

Rust: Async runtime بخشی از Stack است

async/await زبان، Future می‌سازد اما انتخاب Runtime، Executor، Timer و I/O driver در Stack اثر دارد. کتاب رسمی Rust درباره Async توضیح می‌دهد Runtimeهای ثالث Task/Future را هماهنگ می‌کنند. Blocking work را روی Executor async اجرا نکنید؛ مسیر جدا یا Pool محدود بسازید.

Node.js: Event Loop را منصف نگه دارید

JSON بزرگ، Regex آسیب‌پذیر، Compression، Crypto sync یا Loop طولانی می‌تواند Clientهای دیگر را معطل کند. برای CPU قابل‌توجه، Worker Threads یا Process/service جدا را Pilot کنید؛ هزینه Serialization/Transfer، Pool و Failure isolation را بسنجید. افزودن async به تابع، محاسبه CPU را خودکار از Event Loop خارج نمی‌کند.

مدیریت حافظه و پیش‌بینی‌پذیری

عبارت «Rust بدون GC پس سریع‌تر است» یا «GC مدرن مسئله نیست» هر دو بیش‌ازحد کلی‌اند. رفتار تخصیص Workload را اندازه بگیرید.

در Go، راهنمای رسمی Diagnostics پروفایل CPU/Heap و ابزار pprof را پوشش می‌دهد. برای روش Hypothesis→Trace→Fix→Retest در هر Stack، مقاله پروفایلینگ و دیباگ وب‌اپلیکیشن را ببینید.

امنیت: Memory safety فقط یک لایه است

Rust چه چیزی را کم می‌کند و چه چیزی را نه؟

Safe Rust دسته‌هایی از Use-after-free، Dangling pointer و Data race را با Ownership/Type system محدود می‌کند. اما SQL/Command injection، Broken access control، SSRF، Secret leakage، Dependency compromise، ضعف Cryptography و Race در منطق توزیع‌شده همچنان ممکن‌اند. unsafe و FFI را Inventory، Review و تست جدا کنید.

Go چه ریسک‌هایی دارد؟

Go مدیریت دستی حافظه را از مسیر معمول دور می‌کند، ولی Data race، nil dereference، Panic، Unbounded goroutine، Path traversal و Input validation همچنان مهم‌اند. راهنمای امنیت Go ابزار govulncheck را برای تحلیل آسیب‌پذیری شناخته‌شده و مسیرهای فراخوانی مرتبط پیشنهاد می‌کند.

Node.js چه ریسک‌هایی دارد؟

Dependency و Install script، Prototype pollution، ReDoS، Event-loop blocking، Dynamic evaluation و Secret/config risk را در Threat model بگذارید. Lockfile، Registry policy، کمینه‌سازی Dependency، SCA، Runtime validation و Patch cadence لازم‌اند. «NPM بزرگ» هم مزیت دسترسی به راه‌حل است و هم سطح Supply chain؛ تعداد Package به‌تنهایی معیار کیفیت نیست.

در هر سه گزینه، Authentication/Authorization، Rate limit، Timeout، Secret management، SBOM، Signed artifact، Least privilege و Incident response مستقل از زبان‌اند. برای تبدیل Scan به Gate و Evidence، راهنمای DevSecOps را بخوانید.

اکوسیستم و Dependency: «بزرگ‌تر» لزوماً بهتر نیست

اکوسیستم را با Coverage نیاز خود بسنجید، نه تعداد Package:

• Maintenance activity و Bus factor؛
• License و Compatibility؛
• Security advisory و Patch history؛
• API stability و SemVer behavior؛
• Transitive dependency و Build script؛
• Documentation، Test و Production references؛
• امکان Mirror/Cache و Build reproducible در ایران؛
• Exit path اگر Maintainer یا Registry در دسترس نبود.

Library test قبل از انتخاب زبان

یک Integration کوچک با Database، Queue، Auth، Telemetry و Vendor SDK حیاتی بسازید. فقط «Package وجود دارد» کافی نیست؛ Timeout، Retry، Pool، Cancellation، Error model، TLS و Observability آن را آزمایش کنید.

سرعت توسعه و قابلیت نگهداشت

Time-to-first-endpoint معیار ناقصی است. زمان Change دوم، Debug Incident، Upgrade و Onboarding مهم‌ترند.

عبارت «یک زبان برای Front و Back» بخشی از Context switching را کم می‌کند، اما Front-end و Backend همچنان Domain، Threat و Operation متفاوت دارند. اشتراک Type/Schema ممکن است مزیت باشد؛ اشتراک اشتباه Validation یا Coupling هم ممکن است بدهی بسازد.

معماری مهم‌تر از مسابقه زبان است

زبان خوب، مرز سرویس بد را اصلاح نمی‌کند. پیش از مهاجرت، Connection pool، N+۱، Chatty calls، Cache، Query plan، Payload، Retry storm و Synchronous chain را بررسی کنید. گاهی یک Index یا حذف Round trip بیش از بازنویسی زبان اثر دارد.

مونولیت ماژولار یا میکروسرویس؟

Go بودن دلیل Microservice نیست و Node.js بودن مانع آن نیست. مرز Deployment را با Team ownership، Data consistency، Change cadence و Failure isolation تعیین کنید. راهنمای مونولیت ماژولار یا میکروسرویس این تصمیم را جدا از مُد فناوری تحلیل می‌کند.

API Contract مستقل از Implementation

OpenAPI/GraphQL/Protobuf schema، Error model، Idempotency، Pagination، Compatibility و SLO را پیش از زبان تثبیت کنید. مقاله طراحی API وب قرارداد، امنیت و Reliability را پوشش می‌دهد. اگر بین دو Style API تصمیم دارید، مقایسه GraphQL و REST را ببینید.

استقرار و عملیات

Artifact و Container

• Go: Binary مستقل در بسیاری سناریوها ساده است؛ CGO، libc، timezone/CA و architecture را بررسی کنید؛
• Rust: Binary کنترل‌پذیر است؛ target، libc، native dependency و build time مهم‌اند؛
• Node.js: Runtime، JS artifact و Production dependency همراه‌اند؛ base image، install mode و native addon را کنترل کنید.

Image size کوچک به‌تنهایی Outcome نیست. Patchability، SBOM، Startup، Debuggability و Supply-chain provenance را کنار آن بسنجید.

Kubernetes زبان را نجات نمی‌دهد

Resource request/limit، Health/Readiness، Graceful shutdown، Connection draining، HPA signal و Pod disruption برای هر سه Stack لازم‌اند. راهنمای Kubernetes و Containerization Fit و هزینه عملیاتی این لایه را توضیح می‌دهد.

Observability parity

قبل از Pilot مطمئن شوید هر سه گزینه Metric، Log و Trace هم‌معنا تولید می‌کنند: Request ID، Route template، Status class، Dependency span، Queue wait و Runtime metrics. اگر یک گزینه بدون Telemetry مقایسه شود، نتیجه سریع‌تر اما غیرقابل‌عملیات ممکن است انتخاب شود.

هزینه واقعی یا TCO زبان بک‌اند

TCO = build/migration
    + hiring/onboarding/training
    + infrastructure/runtime
    + CI/build/cache/registry
    + observability/on-call/incidents
    + security/patch/compliance
    + upgrades/dependency churn
    + opportunity cost
    + exit/rewrite risk

صرفه‌جویی ۲۰٪ CPU ممکن است در مقیاس بسیار بزرگ ارزشمند باشد؛ در سرویس کوچک، دو ماه تأخیر Release هزینه بیشتری دارد. برعکس، سرعت توسعه اولیه اگر Incident و Resource growth دائمی بسازد، ارزان نیست. سناریوی Low/Likely/High و افق ۱۲ تا ۳۶ماهه بنویسید.

بازار و تیم ایران

• دسترسی به متخصص Mid/Senior و نرخ جایگزینی؛
• زمان آموزش Ownership/Async/Event loop؛
• کیفیت مستندات فارسی/انگلیسی و Mentor داخلی؛
• دسترسی به Registry/Toolchain و Mirror سازمانی؛
• سرعت CI و هزینه Runner/Cache؛
• دسترسی به Vendor SDK، Cloud service و Support؛
• ریسک نرخ ارز برای SaaS tooling؛
• پوشش On-call در تعطیلی و ساعات غیراداری.

ماتریس انتخاب سناریویی

این جدول Recommendation قطعی نیست؛ نقطه شروع Hypothesis است. گزینه‌ای که تیم قبلاً با آن Production موفق دارد، Baseline قدرتمندی است و باید هزینه Opportunity تغییر را شکست دهد.

Benchmark منصفانه: Vertical Slice، نه Hello World

یک Slice واقعی انتخاب کنید

مثلاً Endpoint «ثبت سفارش» با JSON validation، Auth، یک Transaction، یک پیام Outbox، Log/Trace و Error mapping. Contract، Dataset، Container limit و Downstream stub برای سه گزینه یکسان باشد.

پروتکل آزمایش

1. نسخه Toolchain/Framework/Dependency و Commit را ثبت کنید؛
2. Machine/CPU/Memory/Kernel/Container limit را ثابت کنید؛
3. Payload، Dataset، Pool و Timeout را هم‌سطح کنید؛
4. Correctness test را پیش از Load اجرا کنید؛
5. Warm-up و Runهای متعدد داشته باشید؛
6. Baseline، Peak، Burst، Slow dependency و Failure را تست کنید؛
7. P50/P95/P99، Error، CPU، RSS/Heap، GC، Queue و Dependency را ثبت کنید؛
8. ساعت Build، Debug، تست، Deploy و تغییر Requirement را اندازه بگیرید؛
9. نتیجه را با Confidence/Variance و محدودیت گزارش کنید.

Acceptance gate (نمونه، نه عدد جهانی):
- Correctness suite: 100% pass
- Error under target load: within SLO
- p95 / p99: within route SLO
- CPU / memory: within pod budget
- graceful overload and recovery: pass
- telemetry and rollback drill: pass
- implementation + change effort: recorded

بهینه‌سازی منصفانه

به هر گزینه یک Budget زمانی برابر برای Tuning بدهید و Expert bias را ثبت کنید. یک Senior Rust در برابر Junior Node مقایسه زبان نیست. نتیجه را برای همان Stack/Workload معتبر بدانید؛ نه قانون جهانی.

مهاجرت: Big-bang Rewrite نکنید

اگر سیستم فعلی SLO را می‌زند، دلیل قوی برای Rewrite لازم است. مشکلات معماری، Query و Process اغلب در زبان جدید بازتولید می‌شوند. بدهی فنی را با راهنمای Refactor یا Rewrite تفکیک کنید.

نردبان تغییر

1. Measure و رفع گلوگاه در Stack فعلی؛
2. Upgrade Runtime/Framework و تنظیم Pool/Cache؛
3. ایزوله‌کردن CPU job در Worker/Process؛
4. ساخت یک Component یا Service محدود با زبان دیگر؛
5. Shadow traffic و مقایسه خروجی؛
6. Canary با Guardrail؛
7. Cutover و Rollback تمرین‌شده؛
8. گسترش فقط پس از Outcome.

هزینه Polyglot

استفاده هم‌زمان از چند زبان می‌تواند Fit هر Workload را بهتر کند، اما CI، Base image، Security scan، Observability، On-call و Hiring را چندبرابر می‌کند. Platform team باید Paved road برای هر Stack پشتیبانی‌شده بسازد. زبان سوم را برای بهبود جزئی وارد نکنید.

پنج سناریوی تصمیم

۱. MVP فروشگاه با تیم Full-stack کوچک

Node.js/TypeScript می‌تواند Candidate سریع باشد اگر تیم تجربه دارد و Workload بیشتر I/O است. Hard gate: Payment/Shipping SDK، Runtime validation و Supply-chain policy. Pilot باید Checkout و Failure را پوشش دهد، نه فقط CRUD.

۲. Gateway با اتصال هم‌زمان بالا

Go، Rust و Node.js هر سه Candidate‌اند. تفاوت را Backpressure، TLS، Parsing، Timeout، Memory per connection و Operability مشخص می‌کند. Goroutine/Task/Socket نامحدود در هر سه خطرناک است.

۳. پردازش تصویر یا داده CPU-heavy

Rust یا Go ممکن است نسبت به اجرای مستقیم روی Event Loop Node مناسب‌تر باشند؛ اما کتابخانه Native، GPU، Queue و Batch architecture را هم بسنجید. گاهی Node orchestrator + Worker service بهترین مرز است.

۴. سرویس مالی یا امنیتی

Rust memory safety می‌تواند ارزشمند باشد، اما Domain correctness، Decimal، Audit trail، Authorization و Formal test مهم‌ترند. Go یا Node با کنترل قوی نیز ممکن است Fit باشند. Compliance زبان انتخاب نمی‌کند؛ Evidence می‌خواهد.

۵. تیم ایرانی با Registry/CI ناپایدار

Artifact cache، Dependency mirror، Build reproducibility و Offline recovery را در Pilot آزمایش کنید. Binary ساده Go/Rust مزیت احتمالی دارد، اما Toolchain/Crate/Module و Native dependency همچنان باید تامین شود. Node با Cache/Lockfile/Mirror قابل‌مدیریت است؛ فرض «همیشه آنلاین» برای هیچ‌کدام امن نیست.

نقشه ۳۰روزه انتخاب Stack

چک‌لیست نهایی

• Node.js به‌عنوان Runtime/Stack، نه زبان مستقل، مقایسه شده است؛
• نسخه Toolchain، Framework، Driver و Build profile Snapshot دارند؛
• Journey، Workload، SLO، Failure و Constraint تعریف شده‌اند؛
• Hard gateهای SDK، Platform، Team، Security و دسترسی ایران اجرا شده‌اند؛
• CPU-bound از I/O-bound و Concurrency از Parallelism تفکیک شده است؛
• Backpressure، Queue cap، Timeout و Cancellation تست شده‌اند؛
• P50/P95/P99، Error، CPU، Memory و GC/Allocation کنار هم سنجیده شده‌اند؛
• Benchmark یک Vertical slice واقعی و Correctness برابر دارد؛
• Expert bias، Warm-up، Toolchain و Variance گزارش شده‌اند؛
• Memory safety با Web/application security اشتباه نشده است؛
• Dependency، Registry، SBOM، Patch و Mirror ارزیابی شده‌اند؛
• Developer effort، Onboarding، On-call و Exit در TCO هستند؛
• Telemetry و Runbook برای هر Candidate هم‌سطح است؛
• Rewrite فقط پس از رفع/اندازه‌گیری گلوگاه Stack فعلی بررسی شده است؛
• تصمیم با ADR، Scope، Expiry/Review trigger و Rollback ثبت شده است.

جمع‌بندی

Go معمولاً مسیر ساده و منسجمی برای سرویس‌های شبکه‌ای می‌دهد؛ Rust کنترل حافظه و تضمین‌های Compile-time قدرتمندی دارد؛ Node.js/TypeScript برای تیم JavaScript و جریان‌های I/O می‌تواند سرعت تحویل بالایی ایجاد کند. هیچ‌یک بدون Backpressure، Data contract، Security و Operation درست قابل اتکا نیست.

انتخاب حرفه‌ای از سؤال «کدام سریع‌تر است؟» به «کدام Stack با تیم ما، در Workload واقعی، SLO و هزینه تغییر را با شواهد بهتر برآورده می‌کند؟» می‌رسد. یک Service محدود را Pilot کنید، Outcome را بسنجید و تصمیم را قابل بازبینی نگه دارید. اگر روزی نیاز شما تغییر کرد، ADR خوب باید توضیح دهد چرا آن انتخاب در آن زمان درست بوده و چه Triggerی بازنگری را فعال می‌کند.

پرسش‌های متداول

Go، Rust یا Node.js؛ کدام برای بک‌اند سریع‌تر است؟

بدون Workload و Stack مشخص پاسخ معتبری ندارد. Rust در کنترل سطح پایین، Go در سرویس شبکه و Node.js در I/O می‌توانند مزیت داشته باشند؛ اما Driver، معماری، Tail latency، Error، CPU/Memory و مهارت تیم باید در Pilot هم‌سطح سنجیده شوند.

آیا Rust همیشه امن‌تر از Go و Node.js است؟

Rust در Safe code تضمین‌های مهم Memory safety و Concurrency می‌دهد، اما امنیت کامل وب نیست. Injection، Authorization، SSRF، Secret، Dependency و Business logic در هر سه Stack نیازمند طراحی و تست‌اند؛ unsafe/FFI نیز مرز جدا دارد.

آیا Node.js برای CPU-heavy مناسب نیست؟

اجرای محاسبه طولانی روی Event Loop مناسب نیست، چون Clientهای دیگر را معطل می‌کند. می‌توان Worker thread، Process، Native/WebAssembly یا سرویس جدا به‌کار برد؛ انتخاب به هزینه انتقال، Pool، Failure isolation و Benchmark بستگی دارد.

برای میکروسرویس Go بهترین انتخاب است؟

Go Candidate خوبی است، اما «میکروسرویس» Hard requirement زبان نیست. Team ownership، Data boundary، Deployment، SDK، SLO و Operation تعیین‌کننده‌اند. گاهی مونولیت ماژولار در Stack فعلی هزینه و ریسک کمتری دارد.

چطور بین این سه گزینه تصمیم نهایی بگیریم؟

Decision contract و Hard gate بسازید؛ یک Vertical slice واقعی با Contract/Dataset/Resource برابر پیاده کنید؛ Correctness، P95/P99، Error، CPU/Memory، امنیت، عملیات و ساعت مهندسی را بسنجید؛ سپس ADR محدود به Scope با Canary و Rollback ثبت کنید.