#تصمیم‌های_مهندسی (Engineering Decisions)
یکی از تصمیم‌هایی که تقریباً هر تیمی دیر یا زود با آن روبه‌رو می‌شود، این است:
«آیا برای این قابلیت، از Cache استفاده کنیم یا نه؟»
جالب است که در بسیاری از تیم‌ها، این سؤال زمانی مطرح می‌شود که Performance افت کرده است.
اما سؤال درست، چیز دیگری است.
«آیا اصلاً مشکل ما، نداشتن Cache است؟»
بارها دیده‌ام اولین راه‌حل پیشنهادی برای کاهش زمان پاسخ، اضافه کردن Redis یا Memory Cache بوده است.
در حالی که بعد از اندازه‌گیری مشخص شده:
ءQuery اشتباه نوشته شده است.
ءN+1 Query رخ می‌دهد.
یک API خارجی گلوگاه سیستم است.
یا حتی بخش زیادی از زمان صرف Serialization می‌شود.
در چنین شرایطی، Cache فقط صورت مسئله را پنهان می‌کند.
نه اینکه آن را حل کند.
به همین دلیل، تصمیم استفاده از Cache نباید یک تصمیم Performance باشد.
باید یک تصمیم معماری باشد.
یعنی قبل از هر چیز باید بدانیم:
آیا داده به اندازه کافی پایدار است؟
آیا Consistency لحظه‌ای برای Business اهمیت دارد؟
هزینه Invalidating Cache چقدر است؟
اگر Cache از دسترس خارج شود، سیستم چه رفتاری خواهد داشت؟
اگر جواب این سؤال‌ها روشن نباشد،
اضافه کردن Cache، بیشتر شبیه قرض گرفتن از آینده است تا بهینه‌سازی.
چون در مهندسی نرم‌افزار،
بهترین تصمیم همیشه این نیست که سیستم را سریع‌تر کنیم.
گاهی بهترین تصمیم این است که اول دلیل کند بودن آن را بفهمیم.