#تصمیم‌های_مهندسی (Engineering Decisions)
یکی از تصمیم‌هایی که تقریباً هر تیمی دیر یا زود با آن روبه‌رو می‌شود این است:
«آیا این عملیات باید Synchronous باشد یا Asynchronous؟»
خیلی‌ها به‌محض شنیدن کلمه Asynchronous تصور می‌کنند با انتخاب آن، سیستم سریع‌تر می‌شود.
اما سؤال اصلی چیز دیگری است.
آیا کاربر واقعاً لازم است منتظر بماند؟
فرض کنید کاربری سفارشی ثبت می‌کند.
بعد از ثبت سفارش باید:
ایمیل ارسال شود.
پیامک ارسال شود.
فاکتور تولید شود.
موجودی انبار به‌روزرسانی شود.
ءNotification برای مدیر ارسال شود.
آیا همه این کارها باید قبل از دریافت پاسخ HTTP انجام شوند؟
اگر جواب نه باشد، شاید نگه داشتن کاربر پشت این عملیات، فقط Latency سیستم را بیشتر کرده باشد.
اما طرف دیگر ماجرا هم مهم است.
اگر همه چیز را Asynchronous کنیم،
حالا باید با چالش‌های جدیدی کنار بیاییم:
پیام تکراری (Duplicate Messages)، ترتیب پیام‌ها (Ordering)، تحویل حداقل یک‌بار (At-Least-Once Delivery)، Idempotency، مانیتورینگ صف‌ها،
مدیریت خطا و Retry.
یعنی مسئله فقط عوض شده است؛ از بین نرفته.
به همین دلیل، مهندسان باتجربه اول از خودشان نمی‌پرسند:
«چطور این را Asynchronous کنیم؟»
بلکه می‌پرسند:
«کاربر واقعاً منتظر نتیجه این عملیات است یا نه؟»
چون در مهندسی نرم‌افزار، Synchronous و Asynchronous، خوب یا بد نیستند.
هر کدام، هزینه‌ها و مزایای خودشان را دارند.
و تصمیم درست،
همان تصمیمی است که با نیاز واقعی سیستم هم‌خوانی داشته باشد.