برای چه پروژه‌هایی نباید از n8n استفاده کنید؟ بررسی محدودیت‌های فنی و عملیاتی

این یادداشت نه برای تخریب ابزار  n8n نوشته شده و نه یک ریپورتاژ آگهی برای فروش دوره آموزشی یا سرویس میزبانی آن است. این روزها فضای وب پر شده از محتواهای هیجانی و هایپ که وعده می‌دهند با ابزارهای No-Code می‌توانید کل تیم فنی را اخراج کنید و همه چیز را با چند کلیک ساده بسازید! اما به عنوان مهندس نرم‌افزار می‌دانم که واقعیت پیچیده‌تر است.

من این پست را نوشتم تا تجربیات تلخ و شیرین در محیط‌های Production واقعی را با شما در میان بگذارم. هدفم این است که اگر روزی مدیرعامل از شما پرسید «چرا همه چیز را با n8n نمی‌سازیم؟»، شما استدلال فنی، منطقی و معماری‌محور برای پاسخ داشته باشید. این یک گفتگوی تمام فنی، به دور از هیاهوهای بازاریابی است. پس اگر دنبال واقعیت‌های فنی (حتی اگر تلخ باشند) هستید، با من همراه باشید.

n8n فراتر از تبلیغات

بیایید روراست باشیم، n8n (Nodemation) یک ابزار فوق‌العاده است. چند سال پیش وقتی اولین بار با آن کار کردم، حس آزادی عجیبی داشتم. اینکه بتوانید یک Webhook را به یک دیتابیس وصل کنید، داده‌ها را با کمی جاوا اسکریپت دستکاری کنید و نتیجه را به Slack بفرستید، آن هم در عرض ۱۵ دقیقه، واقعاً جذاب است. جنبش Low-Code/No-Code وعده دموکراتیزه کردن اتوماسیون را داده بود و n8n یکی از پرچمداران شایسته این جنبش است که با رویکرد Fair-code و قابلیت Self-Hosted، دل بسیاری از توسعه‌دهندگان را به دست آورده است.

اما… و این یک “امای” بزرگ است؛ ما مهندسان نرم‌افزار می‌دانیم که در دنیای نرم افزار “راه حل جادویی” (Silver Bullet) وجود ندارد. هر ابزاری، هرچقدر هم قدرتمند، بر اساس یک معماری خاص و برای حل دسته‌ای خاص از مشکلات طراحی شده است. وقتی سعی می‌کنیم ابزاری را در جایی که برای آن ساخته نشده به کار بگیریم، بدهی فنی (Technical Debt) شروع به انباشته شدن می‌کند و فاجعه معمولاً زمانی رخ می‌دهد که سیستم زیر بار Production است.

در این یادداشت طولانی و عمیق، می‌خواهم کلاه “طرفدار n8n” را بردارم و کلاه “مهندس معمار نرم افزار” را سرم بگذارم. می‌خواهیم با هم بررسی کنیم که کجا خط قرمز n8n است؟ چه زمانی استفاده از آن اشتباه است؟ و چرا برای برخی پروژه‌های خاص، پافشاری بر استفاده از n8n می‌تواند به شکست پروژه یا کابوس‌های شبانه برای تیم DevOps منجر شود. ما محدودیت‌های ذاتی Node.js، چالش‌های مدیریت State، مشکلات مقیاس‌پذیری (Scalability) و امنیت را زیر ذره‌بین خواهیم برد.

قدرت و محدودیت‌های n8n

قبل از اینکه به سراغ نقاط ضعف برویم، باید بفهمیم n8n دقیقاً چیست و چرا معماری آن چنین محدودیت‌هایی را دیکته می‌کند.

n8n چیست؟ (مروری کوتاه بر ماهیت Low-Code و Node-Based بودن آن)

n8n یک ابزار Workflow Automation مبتنی بر Node یا گره است. در اصل، این ابزار با TypeScript نوشته شده و بر روی محیط اجرایی Node.js اجرا می‌شود. هر “Node” در n8n در واقع یک تابع جاوا اسکریپت یا یک Wrapper دور یک API است. وقتی شما یک Workflow می‌سازید، در حال تعریف یک زنجیره از اجراها هستید که داده‌ها (به صورت JSON Objects) بین آن‌ها پاس داده می‌شوند.

جذابیت اصلی این ابزار در سه چیز است:

1. سهولت استفاده: رابط کاربری بصری (UI) که پیچیدگی منطق کد را پنهان می‌کند.

2. گستردگی Nodes: صدها نود آماده برای سرویس‌های مختلف.

3. انعطاف‌پذیری در استقرار: شما می‌توانید آن را روی لپ‌تاپ خود، یک سرور مجازی حدود به 500 هزارتومان یا کلاستر Kubernetes اجرا کنید.

نکته فنی کلیدی: معماری Event-Driven و اجرای فرآیندها

معماری n8n بر اساس رویداد (Event-Driven) است، اما نحوه اجرای آن نکات ظریفی دارد. در حالت پیش‌فرض، n8n ورک‌فلوها را روی همان فرآیند اصلی (Main Process) اجرا می‌کند (مگر اینکه Worker جداگانه تنظیم کرده باشید). از آنجایی که Node.js ذاتا Single-Threaded است (با وجود Event Loop)، عملیات سنگین CPU-Bound می‌تواند کل اینستنس را بلاک کند.

حتی با وجود Workerها، مدل انتقال داده در n8n به این صورت است که خروجی هر نود باید کامل شود تا نود بعدی شروع به کار کند (مگر در موارد خاص). این یعنی ما با یک مدل سریال (Serial) یا موازی محدود طرف هستیم، نه یک سیستم توزیع‌شده واقعی که بتواند هزاران Thread را همزمان مدیریت کند. این معماری برای انتقال داده‌های سبک بین سرویس‌های SaaS عالی است، اما وقتی صحبت از پردازش‌های سنگین یا تضمین‌های سخت‌گیرانه می‌شود، کم می‌آورد.

شناخت نقاط ضعف برای انتخاب درست

بسیاری از مدیران محصول یا حتی توسعه‌دهندگان تازه‌کار، تفاوت بین Workflow Automation و Process Orchestration یا Integration Platform های سطح Enterprise را نادیده می‌گیرند.

• n8n یک ابزار اتوماسیون گردش کار است. یعنی: “وقتی X اتفاق افتاد، Y را انجام بده”.

• این ابزار برای MVPها (حداقل محصول قابل ارائه)، اتوماسیون‌های داخلی تیم‌ها (مثل ربات‌های تلگرام/اسلک)، و ادغام‌های سبک (Sync کردن کانتکت‌های گوگل با CRM) ایده‌آل است.

اما وقتی پروژه از فاز MVP خارج می‌شود و به یک سیستم حیاتی (Mission Critical) تبدیل می‌شود، استفاده از n8n ممکن است دیگر توجیه پذیر نباشد. بیایید وارد جزئیات شویم.

پروژه‌های بحرانی با SLA بالا (99.999%)

اولین و مهم‌ترین جایی که باید دور n8n را خط قرمز بکشید، سیستم‌هایی هستند که نیاز به دسترسی‌پذیری بسیار بالا (High Availability) و SLAهای سخت‌گیرانه دارند.

الزامات آپتایم 99.999% برای بقا

بیایید کمی به زبان ریاضی صحبت کنیم. وقتی مدیری می‌گوید “سیستم ما نباید قطع شود”، معمولاً منظورش SLA با پنج‌تا ۹ (99.999%) است.

• 99.9% (Three Nines): حدود ۸ ساعت و ۴۶ دقیقه خرابی مجاز در سال. (n8n با یک تنظیم خوب حدودا می‌تواند به این حد برسد).

• 99.999% (Five Nines): حدود ۵ دقیقه و ۱۵ ثانیه خرابی مجاز در سال!

رسیدن به 5 دقیقه Downtime در سال، نیازمند معماری‌ای است که در آن هیچ نقطه شکست واحدی (Single Point of Failure – SPOF) وجود نداشته باشد و Failover (سوییچ به سرور یدکی) در کسری از ثانیه انجام شود.

High Availability (HA) و Failover

مفهوم HA فقط به معنای روشن بودن سرور نیست. HA یعنی حفظ عملکرد سیستم حتی در صورت خرابی اجزا. این نیازمند:

1. Load Balancing هوشمند: توزیع ترافیک بین چندین سرور.

2. State Synchronization: همه سرورها باید بدانند ورک‌فلو در چه مرحله‌ای است.

3. Automatic Failover: اگر سرور A آپ نبود، سرور B بلافاصله ادامه کار را بدون دخالت انسان به عهده بگیرد.

زمان مورد نیاز برای بازیابی (RTO – Recovery Time Objective) در سیستم‌های حیاتی باید نزدیک به صفر باشد.

چالش n8n در HA

n8n در حالت Self-Hosted امکاناتی برای Scaling با استفاده از Workerها و Redis ارائه می‌دهد، اما پیکربندی آن برای رسیدن به HA واقعی (True HA) بسیار پیچیده و گاهی ناپایدار است. مدیریت State در n8n (اینکه کدام نود اجرا شد، خروجی‌اش چه بود و نود بعدی چیست) در دیتابیس ذخیره می‌شود. اگر در لحظه‌ای که دیتابیس زیر فشار است یا ارتباط بین Main Process و Worker قطع شود، ممکن است وضعیت یک Execution گم شود یا در حالت Unknown بماند. n8n مکانیزم‌های بومی و داخلی قدرتمندی برای Leader Election (انتخاب رهبر جدید در کلاستر در صورت مرگ رهبر قبلی) به آن صورتی که ابزارهایی مثل Kubernetes یا Zookeeper مدیریت می‌کنند، ندارد. شما باید خودتان با ابزارهای جانبی این را وصله پینه کنید.

چرا n8n بهترین انتخاب نیست؟ (چالش‌های Availability و Reliability)

1. Single Point of Failure (SPOF)

حتی اگر شما ۱۰ تا Worker هم داشته باشید، معماری n8n معمولاً به یک دیتابیس SQL مرکزی (PostgreSQL) وابسته است. اگر این دیتابیس دچار Lock شود یا پاسخ ندهد، تمام اتوماسیون‌ها متوقف می‌شوند. همچنین، فرآیند اصلی (Webhook Receiver) می‌تواند گلوگاه شود. اگر کانتینر اصلی n8n کرش کند، دریافت Webhookها تا زمان بالا آمدن مجدد کانتینر متوقف می‌شود (مگر اینکه لایه Load Balancer جداگانه‌ای قبل از آن داشته باشید که باز هم پیچیدگی را بالا می‌برد).

2. مدیریت Error و Retry تخصصی

در سیستم‌های بانکی یا پزشکی، “تلاش مجدد” (Retry) ساده کافی نیست. ما نیاز به الگوهایی مثل:

• Dead Letter Queue (DLQ): پیام‌هایی که پردازش نمی‌شوند باید به یک صف جداگانه بروند تا بعداً بررسی شوند، نه اینکه گم شوند.

• Circuit Breaker: اگر سرویس مقصد خراب است، سیستم نباید مدام درخواست بفرستد و منابع را هدر دهد؛ باید “مدار را قطع کند”.

n8n قابلیت Error Workflow و Retry دارد، اما پیاده‌سازی الگوهای پیشرفته مثل Circuit Breaker یا Saga Pattern (برای تراکنش‌های توزیع‌شده) در آن نیازمند “کدنویسی زیاد” درون n8n است. وقتی مجبورید داخل یک ابزار Low-Code هزار خط کد بنویسید تا پایداری ایجاد کنید، یعنی ابزار اشتباهی انتخاب کرده‌اید.

راهکار جایگزین

برای این سطح از حساسیت، پلتفرم‌های Cloud Native مثل AWS Step Functions یا Azure Logic Apps گزینه‌های بهتری هستند. این سرویس‌ها Serverless هستند، مدیریت State را خودشان انجام می‌دهند و SLAهای بسیار بالایی را توسط غول‌های ابری تضمین می‌کنند. یا ابزارهای Orchestration مثل Temporal.io که اساساً برای تضمین اجرای کد (“Code Executed Exactly Once”) طراحی شده‌اند.

پردازش حساس اطلاعات و انطباق (Compliance)

در پروژه‌های Enterprise، امنیت فقط “هک نشدن” نیست، بلکه Compliance (انطباق با قوانین) است. استانداردهایی مثل GDPR (اروپا)، HIPAA (پزشکی)، و PCI DSS (پرداخت) نیازمندی‌های سخت‌گیرانه‌ای دارند.

• Audit Logging: شما باید دقیقا بدانید چه کسی، در چه زمانی، ورک‌فلو را تغییر داده و چه داده‌ای عبور کرده است. n8n لاگ‌های اجرایی دارد، اما سیستم Audit Trail آن برای استانداردهای بانکی کافی نیست (مثلاً لاگ تغییرات پیکربندی نودها با جزئیات کامل و غیرقابل دستکاری).

• IAM (Identity and Access Management): مدیریت دسترسی‌ها در n8n (حتی در نسخه Enterprise) نسبت به ابزارهای سازمانی محدودتر است. کنترل دقیق اینکه کدام کاربر بتواند کدام Credentials را ببیند یا کدام نود را ویرایش کند، چالش‌برانگیز است.

• رمزنگاری: n8n داده‌ها را در دیتابیس ذخیره می‌کند. مدیریت کلیدهای رمزنگاری (KMS) و رمزنگاری End-to-End در سطح اپلیکیشن، نیازمند تنظیمات زیرساختی است و خود اپلیکیشن به صورت Native برخی ویژگی‌های پیشرفته امنیتی Enterprise را ندارد.

نیازمندی‌های پیچیده انتقال داده (ETL/ELT)

دومین دسته‌ای که n8n در آن ضعف جدی نشان می‌دهد، پردازش حجم بالای داده یا همان ETL (Extract, Transform, Load) است.

حجم عظیم داده و تبدیل‌های پیچیده (Transformation)

بیایید تفاوت Data Integration و Data Pipeline را مشخص کنیم.

• Data Integration: وقتی کاربر فرم پر کرد، اطلاعاتش را بفرست به CRM. (مناسب n8n).

• Data Pipeline: هر شب ۱۰ گیگابایت لاگ را از S3 بخوان، فرمت تاریخ‌ها را عوض کن، رکوردهای تکراری را حذف کن و در BigQuery بریز. (نامناسب برای n8n).

Bottleneck عملکردی: پردازش داده در حافظه (In-Memory Processing)

پاشنه آشیل n8n در پردازش داده‌های حجیم، نحوه مدیریت حافظه آن است. وقتی شما یک فایل JSON یا CSV را در n8n می‌خوانید، این ابزار سعی می‌کند کل داده را به عنوان یک آرایه از اشیاء JSON در حافظه (RAM) بارگذاری کند تا بتواند آن‌ها را به نود بعدی پاس دهد.

مشکل Out-of-Memory (OOM) در نود NodeJS

اینجا دقیقا جایی است که محدودیت‌های V8 Engine گریبان‌گیر می‌شود.

1. محدودیت Heap: فرآیندهای Node.js به طور پیش‌فرض محدودیت حافظه (Heap Size) دارند (مثلاً حدود ۱.۵ تا ۲ گیگابایت در سیستم‌های ۶۴ بیتی قدیمی‌تر، هرچند قابل افزایش است).

2. سربار JSON: یک فایل CSV صد مگابایتی، وقتی پارس (Parse) شده و به آبجکت‌های جاوا اسکریپت تبدیل می‌شود، ممکن است ۵۰۰ یا ۶۰۰ مگابایت از RAM را اشغال کند.

3. کپی‌برداری داده: در n8n، وقتی داده از نود A به نود B می‌رود، گاهی کپی‌هایی از داده در حافظه ایجاد می‌شود.

اگر سعی کنید یک فایل ۵۰۰ مگابایتی را پردازش کنید، به احتمال زیاد با خطای ترسناک:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

مواجه می‌شوید و کانتینر شما کرش می‌کند.

راهکار نامناسب: افزایش max-old-space-size

بسیاری از مهندسان سعی می‌کنند با فلگ --max-old-space-size در نود جی‌اس، حافظه را به ۸ یا ۱۶ گیگابایت افزایش دهند. این فقط یک مسکن موقتی است. Node.js برای مدیریت Garbage Collection (GC) روی هیپ‌های بسیار بزرگ بهینه نشده است. وقتی GC اجرا می‌شود، می‌تواند کل برنامه را برای چند ثانیه (یا دقیقه) فریز کند (Stop-the-world pause) که باعث Timeout شدن درخواست‌ها می‌شود.

محدودیت در Transformationهای تخصصی

علاوه بر حافظه، n8n ابزارهای بومی برای انجام عملیات پیچیده روی داده (مثل Joinهای پیچیده بین میلیون‌ها رکورد، Aggregationهای سنگین و…) را ندارد. شما مجبورید از نود Code و جاوا اسکریپت خالص استفاده کنید که باز هم کند و تک‌هسته‌ای (Single-Threaded) است. n8n نمی‌تواند مثل Apache Spark پردازش را روی ۱۰ سرور توزیع کند.

ابزارهای تخصصی ETL و جایگزین‌ها

برای پروژه‌های داده‌محور، باید از ابزارهایی استفاده کنید که برای Streaming یا Batch Processing توزیع‌شده طراحی شده‌اند.

• Apache Airflow: متخصص ارکستراسیون داده، با زبان پایتون و تعریف DAGها، مدیریت وابستگی‌های پیچیده را آسان می‌کند.

• Apache NiFi: اگر محیط بصری (Visual) مثل n8n را دوست دارید اما قدرت پردازش داده‌های حجیم را می‌خواهید، NiFi گزینه مناسبی است. این ابزار داده‌ها را به صورت FlowFile و با مدیریت بافر دیسک (نه فقط RAM) منتقل می‌کند.

• Meltano / Airbyte: برای بخش Extract و Load (EL) مدرن بسیار کارآمدتر هستند.

کاربردهای Real-time با تاخیر صفر (Low-Latency) 

سومین منطقه ممنوعه برای n8n، سیستم‌های Real-time حساس به تاخیر است.

سیستم‌های معاملاتی الگوریتمی و واکنش سریع

فرض کنید در حال ساخت سیستمی برای بورس یا ترید ارز دیجیتال هستید که باید به محض تغییر قیمت، دستور خرید صادر کند. یا یک سیستم IoT صنعتی که باید با تشخیص نشت گاز، در کمتر از ۵۰ میلی‌ثانیه شیر را ببندد. در این سناریوها، تاخیر (Latency) دشمن شماره یک است.

مفهوم Latency در n8n

چرا n8n کند است؟ (البته کند در مقیاس میلی‌ثانیه).

1. HTTP Overhead: اکثر تریگرهای n8n مبتنی بر Webhook (HTTP) هستند. ایجاد کانکشن HTTP، هندشیک TLS و پارس کردن Body زمان‌بر است.

2. Workflow Loading: وقتی یک درخواست می‌آید، n8n باید فایل JSON ساختار ورک‌فلو را بخواند (یا از کش بیاورد)، نودها را مقداردهی کند و اجرا را آغاز کند.

3. Node Execution Overhead: عبور از هر نود در n8n، سربار نرم‌افزاری دارد (Validate کردن ورودی، اجرای تابع، فرمت کردن خروجی).

در یک تست ساده، یک ورک‌فلو ساده در n8n ممکن است بین ۲۰۰ تا ۵۰۰ میلی‌ثانیه (در بهترین حالت) تا چند ثانیه (زیر بار) تاخیر داشته باشد. برای یک کاربر انسانی که منتظر ایمیل است، این عالی است. برای یک ربات معامله‌گر فرکانس بالا (HFT)، این یعنی فاجعه.

عدم پشتیبانی از Stream Processing

n8n اساساً یک سیستم Message Broker نیست.

• Polling: بسیاری از نودهای n8n برای دریافت تغییرات، هر ۱ دقیقه یا ۵ دقیقه سرویس مقصد را “Poll” (چک) می‌کنند. این یعنی ذاتاً Real-time نیستند.

• Streaming: ابزار n8n نمی‌تواند یک “جریان داده بی‌پایان” (Unbounded Stream) را باز نگه دارد و پردازش کند. رویکرد آن Batch یا Micro-Batch است (یک اجرا شروع می‌شود و تمام می‌شود).

جایگزین‌های مناسب

اگر نیاز به پردازش Real-time دارید:

• برای انتقال پیام: Apache Kafka، RabbitMQ یا Redis Streams.

• برای پردازش: Apache Flink یا Spark Streaming. این ابزارها می‌توانند میلیون‌ها رویداد در ثانیه را با تاخیر زیر ۱۰ میلی‌ثانیه پردازش کنند.

وقتی نیاز به کنترل دقیق زیرساخت دارید (DevOps/SRE) 

دسته‌ی آخر، پروژه‌هایی هستند که تیم DevOps یا SRE (Site Reliability Engineering) نیاز به کنترل میکروسکوپی روی منابع دارد.

مدیریت منابع و مقیاس‌پذیری پیشرفته

در معماری میکروسرویس مدرن، ما عادت کرده‌ایم برای هر سرویس، منابع (CPU/RAM) مشخصی تعریف کنیم (Resource Quotas/Limits در کوبرنتیز).

مشکل “جعبه سیاه” در n8n

در n8n، شما صدها ورک‌فلو مختلف دارید که همگی درون یک یا چند کانتینر Worker اجرا می‌شوند.

• عدم ایزولاسیون: اگر ورک‌فلو A دارای یک لوپ بی‌نهایت باشد یا مموری زیادی مصرف کند، می‌تواند ورک‌فلو B (که حیاتی است) را هم تحت تأثیر قرار دهد چون هر دو در یک کانتینر Node.js هستند.

• مقیاس‌پذیری غیردقیق: شما نمی‌توانید بگویید “برای ورک‌فلوی پرداخت، ۱۰ گیگ رم اختصاص بده و برای ورک‌فلوی ارسال ایمیل، ۵۰۰ مگابایت”. شما مجبورید کل Workerها را Scale کنید. این یعنی هدررفت منابع.

انعطاف‌پذیری محدود n8n در تنظیمات سرور

n8n ابزاری است که “همین است که هست”. اگرچه می‌توانید ماژول‌های npm اضافه کنید، اما نمی‌توانید به راحتی Runtime آن را دستکاری کنید.

• زبان: شما محدود به Node.js هستید. اگر یک الگوریتم فشرده‌سازی سنگین دارید که در Go یا Rust ده برابر سریع‌تر اجرا می‌شود، ادغام آن در n8n (به صورت Native و نه فراخوانی خارجی) دردسر دارد.

• Observability: ابزارهای مدرن از OpenTelemetry برای ردیابی (Tracing) درخواست‌ها در کل سیستم استفاده می‌کنند. اگرچه n8n در حال پیشرفت است، اما ادغام عمیق آن با سیستم‌های مانیتورینگ مثل Prometheus و Grafana (برای دیدن متریک‌های داخلی هر ورک‌فلو) هنوز به بلوغ ابزارهای Enterprise نرسیده است. دیباگ کردن اینکه “چرا این ورک‌فلو دیروز ساعت ۳ کند شد” در n8n بدون لاگ‌برداری دستی سخت است.

جایگزین‌های مناسب

برای کنترل کامل زیرساخت، نوشتن Microservices (با Go, Java, Python) و مدیریت آن‌ها با Kubernetes بهترین راه است. این به شما اجازه می‌دهد ایزولاسیون کامل، مقیاس‌پذیری دقیق (HPA بر اساس متریک‌های کاستوم) و مانیتورینگ عمیق داشته باشید.

نتیجه‌گیری بعد از یه بحث طولانی

بیایید جمع‌بندی کنیم که طولانی شد، آیا من می‌گویم n8n را دور بیندازید؟ به هیچ وجه! من خودم برای کارهای روزمره و اتصال سرویس‌های اطلاع رسانی شرکت از n8n استفاده می‌کنم. n8n استاد “چسباندن سریع سرویس‌ها به هم” است.

اما به عنوان یک مهندس نرم افزار، وظیفه ما این است که فریب جو تبلیغاتی را نخوریم.

• اگر پروژه شما مرگ و زندگی است (SLA 99.999%)، n8n ریسک بالایی دارد.

• اگر قرار است ترابایت‌ها داده جابجا کنید (Big Data ETL)، n8n زیر بار حافظه کم می‌آورد.

• اگر نیاز به پاسخ‌دهی زیر ۱۰ میلی‌ثانیه دارید (Real-time)، معماری n8n برای این کار نیست.

• اگر تیم DevOps شما نیاز به کنترل دقیق منابع برای هر فرآیند دارد، n8n یک جعبه سیاه بزرگ است.

n8n یک “Middleware” عالی است، نه یک “Core Engine” برای سیستم‌های حیاتی.

انتخاب ابزار، مثل انتخاب مصالح ساختمانی مهم است. شما می‌توانید با چوب یک کلبه جنگلی زیبا (یک MVP) بسازید، اما اگر بخواهید یک برج ۵۰ طبقه (سیستم Enterprise مقیاس‌پذیر) بسازید، به فولاد و بتن (Microservices, Kafka, K8s) نیاز دارید. اصرار بر ساختن برج با چوب، فقط باعث فرو ریختن آن بر سر ساکنانش می‌شود.

امیدوارم این راهنما به شما کمک کند تا در جلسه بعدی معماری نرم افزار، با اعتماد به نفس و استدلال فنی، ابزار درست را برای کار درست انتخاب کنید و همچنین مثل همیشه منتظر دیدگاه ارزشمند شما هستم.