کالبدشکافی یک مهاجرت بزرگ: چرا ردیت قلب تپنده‌اش را به Go سپرد؟

اخیراً تیم مهندسی Reddit یکی از مهم‌ترین تغییرات زیرساختی چند سال اخیر خود را فاش کرد: بازنویسی سرویس کامنت‌ها (Comment Service) از پایتون به Go.
شاید بپرسید چرا کامنت؟ در ردیت، کامنت‌ها فقط یک لیست ساده متنی نیستند؛ آن‌ها یک ساختار درختی پیچیده و عمیق (Deeply Nested) دارند که پردازش و نمایش آن‌ها در اسکیل میلیونی، یک چالش تمام عیار مهندسی است.


چرا پایتون دیگر پاسخگو نبود؟ (The Bottleneck)

ردیت سال‌هاست که یک "Python Shop" محسوب می‌شود. پایتون برای توسعه سریع عالی است، اما وقتی صحبت از High Throughput و محاسبات سنگین در لحظه می‌شود، کم می‌آورد:
۱. هزینه بالای ساخت آبجکت‌ها: در پایتون، هر نود (Node) در درخت کامنت‌ها یک آبجکت سنگین است. وقتی قرار است هزاران کامنت را برای یک ترد (Thread) لود کنید، سربار حافظه و CPU وحشتناک می‌شود.

۲. قفل مفسر جهانی (GIL): پردازش همزمان درخواست‌ها در پایتون به دلیل GIL محدودیت دارد و نمی‌توان از تمام هسته‌های CPU به صورت واقعی (Parallelism) بهره برد.

۳. تایپ‌دهی پویا: در سیستم‌های بسیار بزرگ، چک کردن تایپ‌ها در زمان اجرا (Runtime) هم سربار دارد و هم ریسک باگ را بالا می‌برد.

چرا Go ناجی سیستم شد؟
تیم ردیت تصمیم گرفت برای این سرویس خاص به سراغ Go برود. نتایج خیره‌کننده بود:

✅ مدیریت همزمانی (Concurrency): با استفاده از Goroutineها، ردیت توانست درخواست‌های واکشی (Fetch) کامنت‌ها را به صورت موازی و بسیار سبک انجام دهد. کاری که در پایتون نیازمند Threadهای سنگین سیستم‌عامل بود، در Go با چند کیلوبایت حافظه انجام شد.

✅ ساختار داده‌ای بهینه: برخلاف پایتون، Go اجازه می‌دهد کنترل دقیقی روی نحوه چیدمان داده‌ها در حافظه داشته باشید (Memory Layout). این یعنی کاهش فشار روی Garbage Collector و افزایش سرعت پردازش.

✅ کاهش تاخیر (Latency): نتیجه نهایی، کاهش چشمگیر زمان پاسخگویی (Response Time) سرویس کامنت بود، حتی در زمان‌هایی که ترافیک پلتفرم به اوج می‌رسد.

درس‌هایی برای طراحی سیستم (System Design):
این حرکت ردیت یک کلاس درس عالی برای معماران نرم‌افزار است:
- معماری چند زبانه (Polyglot): لازم نیست کل پلتفرم با یک زبان نوشته شود. ردیت همچنان برای بیزنس لاجیک‌های لایه بالا از پایتون استفاده می‌کند، اما برای لایه‌های زیرین و پرفشار، Go را وارد کرده است.

- میکروسرویس واقعی: جدا کردن سرویس کامنت، اجازه داد تا فقط "همان بخش" اسکیل شود، بدون اینکه نیاز باشد کل کدبیس تغییر کند.

📊 نتیجه: سرویس جدید با منابع سخت‌افزاری کمتر، ترافیک بیشتری را مدیریت می‌کند و تجربه کاربری (UX) روان‌تری را ارائه می‌دهد.

🔗 مطالعه مقاله فنی کامل در ردیت:
https://www.reddit.com/r/RedditEng/s/2tmpQVQSdv

#Reddit #Golang #SystemDesign #Microservices #Backend #PythonVsGo #HighThroughput

🎺برای یادگیری بیشتر و دریافت مطالب مفید در زمینه .NET و برنامه‌نویسی، به کانال ما بپیوندید!

📚💻 @dotnetcode 🖥👨‍💻

🔥 نکته حیاتی در Hangfire: جنگ با ساعت و تایم‌زون‌ها! ⏰🌍

اگر تا حالا براتون پیش اومده که جابی رو برای ساعت ۸ صبح تنظیم کردید ولی ساعت ۱۱:۳۰ اجرا شده، این پست برای شماست!

⚠️ ماجرا چیه؟
هنگ‌فایر (Hangfire) به صورت پیش‌فرض (Default) همه جاب‌های تکرارشونده (Recurring Jobs) رو بر مبنای ساعت UTC اجرا می‌کنه. یعنی اگر تنظیمات تایم‌زون رو بهش ندید، باید اختلاف ساعت ایران با گرینویچ رو دستی حساب کنید که اصلا جالب نیست.

حالا اگر بخوایم بگیم "به وقت ایران اجرا شو"، با یه چالش جدید روبرو می‌شیم:

🔸 ویندوز می‌گه: "Iran Standard Time"

🔸 لینوکس/داکر می‌گه: "Asia/Tehran"
اگر این تفاوت هندل نشه، روی سرور لینوکسی یا کانتینر داکر به خطای TimeZoneNotFoundException می‌خورید! 🤯

✅ راه حل نهایی (Cross-Platform):
با این تیکه کد، هم مشکل UTC رو حل کنید و هم کدی بنویسید که روی ویندوز، لینوکس و مک بدون تغییر کار کنه:

using System.Runtime.InteropServices;

// 1. تشخیص خودکار شناسه تایم‌زون بر اساس سیستم‌عامل
// Windows -> "Iran Standard Time"
// Linux/Docker -> "Asia/Tehran"
var tehranId = RuntimeInformation.IsOSPlatform(OSPlatform.Windows)
  ? "Iran Standard Time"
  : "Asia/Tehran";

// 2. تنظیم ساعت به وقت ایران
RecurringJob.AddOrUpdate(
    type.FullName, 
    () => job.ExecuteAsync(), 
    attribute.CronExpression, 
    new RecurringJobOptions
    {
        // خداحافظ UTC، سلام تهران! 👋
        TimeZone = TimeZoneInfo.FindSystemTimeZoneById(tehranId)
    }
);

💡 با این روش، دیگه نگران جلو/عقب کشیدن ساعت‌ها یا تفاوت محیط لوکال و سرور نباشید.

🔗 بحث مرتبط در کامیونیتی هنگ‌فایر:
https://discuss.hangfire.io/t/need-local-time-instead-of-utc/279/7


🎺برای یادگیری بیشتر و دریافت مطالب مفید در زمینه .NET و برنامه‌نویسی، به کانال ما بپیوندید!

📚💻 @dotnetcode 🖥

#CSharp #DotNet #Hangfire #Docker #Backend #TimeZone #Tips

👩‍💻 هنوز داری با کوئری‌های سنگین دیتابیس رو زیر بار میبری؟

وقتی صحبت از پرفورمنس در PostgreSQL میشه، خیلی‌ها سریع میرن سراغ ایندکس‌گذاری. اما گاهی مشکل ایندکس نیست؛ مشکل اینه که داری یه محاسبات سنگین رو بارها و بارها تکرار می‌کنی!

اینجاست که Materialized View (MatView) وارد بازی میشه. برخلاف View معمولی که فقط یه "پنجره" به دیتاست، MatView نتیجه رو واقعاً روی دیسک ذخیره (Cache) می‌کنه.
اما سوال اصلی اینه: کی باید ازش استفاده کنیم و کی فرار کنیم؟ 🤔

✅ کجا معجزه می‌کنه؟ (Use Cases)
* داشبورد‌های مدیریتی: مدیرها معمولاً آمار لحظه‌ای نمی‌خوان؛ آمار ۵ دقیقه پیش هم راضی‌شون می‌کنه.

* کوئری‌های تحلیلی سنگین: وقتی چند تا Join و Aggregation وحشتناک داری که هر بار اجراش چند ثانیه طول میکشه.

* آرشیو دیتا: وقتی دیتای قدیمی تغییر نمی‌کنه و فقط برای گزارش‌گیری لازمش داری.

❌ کجا نباید سمتش بری؟ (Red Flags)
* دیتای ۱۰۰٪ ریل‌تایم: اگه کاربر باید تغییر رو در میلی‌ثانیه ببینه، MatView گزینه غلطیه (چون تا Refresh نشه، دیتا قدیمیه).

* نرخ تغییرات بالا: اگه دیتای اصلی مدام در حال آپدیته، هزینه Refresh کردن MatView ممکنه بیشتر از سودش بشه.

💡 نکته حرفه‌ای (Pro Tip):

موقع آپدیت کردن ویو، دیتابیس ممکنه قفل بشه! برای اینکه سرویس نخوابه، حتماً از دستور زیر استفاده کن تا همزمان با خوندن، بتونی آپدیتش کنی:

REFRESH MATERIALIZED VIEW CONCURRENTLY

👇 همین الان چک کن:

یه نگاه به لیست Slow Queryهای پروژه‌ت بنداز. اگه کوئری تکراری و سنگین داری، شاید وقتشه "متریالایزش" کنی!

🔗 https://stormatics.tech/blogs/postgresql-materialized-views-when-caching-your-query-results-makes-sense

#PostgreSQL #Database #Performance #Backend #SQL

🎺برای یادگیری بیشتر و دریافت مطالب مفید در زمینه .NET و برنامه‌نویسی، به کانال ما بپیوندید!

📚💻 @dotnetcode 🖥