یادآوری :
شروع تا دقایقی دیگر

پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفه‌ای

وقتی نرخ ورود داده به میلیون‌ها پیام در ثانیه می‌رسد، عامل تعیین‌کننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینه‌ی سخت‌افزار است و نه تکیه بر زیرساخت‌های سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که می‌تواند تفاوت واقعی را رقم بزند.
اخیراً با مقاله‌ای مواجه شدم که دقیقاً همین رویکرد را نشان می‌داد: تیمی که با استفاده از مفاهیم سبک‌وزن مانند goroutine در Go و چند تصمیم مهندسی‌شده، توانسته بودند تنها با یک سخت‌افزار معمولی، بیش از ۱ میلیون پیام در ثانیه را به‌صورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار می‌پردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستم‌های توزیع‌شده.

مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup

چالش‌ها:
- هجوم سنگین داده‌ها از دستگاه‌های IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا

مکانیزم‌هایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام می‌شود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گم‌شدن یا پردازش تکراری داده‌ها.
- مکانیزم Worker Pool کنترل‌شده با goroutine:
به‌جای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیام‌ها را موازی اما کنترل‌شده پردازش می‌کنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون هم‌پوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیام‌های پردازش‌شده به‌صورت گروهی ارسال می‌شوند، مثلاً به دیتابیس یا تاپیک‌های دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صف‌ها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف می‌شود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه می‌دارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخص‌هایی مثل تأخیر پردازش، consumer lag و مصرف CPU به‌صورت لحظه‌ای مانیتور می‌شوند — برای تنظیم سریع و واکنش فوری.

نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیش‌بینی)

نکات مهم برای مهندسان داده و سیستم‌های توزیع‌شده:
- طراحی درست مهم‌تر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستون‌های یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشن‌ها = مقیاس‌پذیری مؤثر
- مانیتورینگ لحظه‌ای = پاسخ سریع به فشارها و خطاها

@DevTwitter | <Mojtaba Banaie/>

🔶 می دونی بدترین صدا در زندگی چیه؟

۱- صدای موتور سیکلت
۲- صدای اسباب بازی بچه شیبه موتور سیکلت 😂

@TheRaymondDev

🔶 به نظر می‌رسد شرکت راکستار در حال کار بر روی افزودن سیستم تأیید سن است و دسترسی به بازی آنلاین GTA 6 برای افراد زیر ۱۸ سال دشوارتر خواهد شد.

#خبر

@TheRaymondDev

پردازش ۱.۲ میلیون پیام در ثانیه با Kafka و Go — معماری سبک اما حرفه‌ای

وقتی نرخ ورود داده به میلیون‌ها پیام در ثانیه می‌رسد، عامل تعیین‌کننده در یک معماری بهینه و سریع و موثر، نه ارتقای پرهزینه‌ی سخت‌افزار است و نه تکیه بر زیرساخت‌های سنگین ابری، بلکه یک طراحی دقیق، ساده و هوشمندانه است که می‌تواند تفاوت واقعی را رقم بزند.
اخیراً با مقاله‌ای مواجه شدم که دقیقاً همین رویکرد را نشان می‌داد: تیمی که با استفاده از مفاهیم سبک‌وزن مانند goroutine در Go و چند تصمیم مهندسی‌شده، توانسته بودند تنها با یک سخت‌افزار معمولی، بیش از ۱ میلیون پیام در ثانیه را به‌صورت پایدار پردازش کنند.
در این پست، به مرور نکات کلیدی این معماری ساده اما تأثیرگذار می‌پردازیم — روایتی کاربردی از دنیای مهندسی داده و سیستم‌های توزیع‌شده.

مقاله اصلی:
Kafka at 1M Messages/Second with Go – Our Exact Pipeline Setup

چالش‌ها:
- هجوم سنگین داده‌ها از دستگاه‌های IoT و کاربران
- نیاز به پردازش بلادرنگ و ارسال همزمان به چند سرویس
- تضمین پایداری، مانیتورینگ دقیق و ریکاوری خودکار در خطا

مکانیزم‌هایی که این معماری را ممکن کردند:
- کامیت دستی offsetها:
تأیید دریافت فقط زمانی انجام می‌شود که پیام کاملاً و با موفقیت پردازش شده باشد — جلوگیری از گم‌شدن یا پردازش تکراری داده‌ها.
- مکانیزم Worker Pool کنترل‌شده با goroutine:
به‌جای ایجاد goroutine برای هر پیام، یک استخر ثابت از goroutineها (به ازای هر پارتیشن کافکا) با طول کانال مشخص و محدود، تعریف شده است که پیام‌ها را موازی اما کنترل‌شده پردازش می‌کنند.
- یک Worker Pool به ازای هر پارتیشن Kafka:
مثلاً با ۱۰ پارتیشن و ۵ goroutine برای هر پارتیشن، در مجموع ۵۰ goroutine داریم — بدون هم‌پوشانی، بدون رقابت اضافه.
- الگوی Dispatcher برای جداسازی دریافت از پردازش:
- بخش اول: فقط دریافت پیام و ارسال به کانال داخلی (یک کانسیومر به ازای هر پارتیشن)
- بخش دوم: پردازش پیام از صف به کمک Worker Pool
- مکانیزم Batching در ارسال خروجی:
پیام‌های پردازش‌شده به‌صورت گروهی ارسال می‌شوند، مثلاً به دیتابیس یا تاپیک‌های دیگر Kafka. این کار فشار ارتباطی را کاهش داده و throughput را بالا برده است.
- اعمال Backpressure هوشمند:
با محدود کردن ظرفیت صف‌ها، اگر سیستم تحت فشار شدید قرار گیرد، مصرف از Kafka موقتاً کند یا متوقف می‌شود تا منابع آزاد شوند. این مکانیزم، از overload جلوگیری کرده و سیستم را در حالت پایدار نگه می‌دارد.
- مانیتورینگ دقیق با Prometheus و Grafana:
شاخص‌هایی مثل تأخیر پردازش، consumer lag و مصرف CPU به‌صورت لحظه‌ای مانیتور می‌شوند — برای تنظیم سریع و واکنش فوری.

نتایج:
- نرخ پردازش: ۱.۲M msg/sec
- تأخیر کل مسیر: <۳ms
- مصرف CPU: ۹۰٪ (پایدار و قابل پیش‌بینی)

نکات مهم برای مهندسان داده و سیستم‌های توزیع‌شده:
- طراحی درست مهم‌تر از افزایش منابع
- انجام commit دقیق، batching و backpressure = ستون‌های یک سیستم مقاوم
- تفکیک دریافت/پردازش + تقسیم کار بین پارتیشن‌ها = مقیاس‌پذیری مؤثر
- مانیتورینگ لحظه‌ای = پاسخ سریع به فشارها و خطاها

| <Mojtaba Banaie/>

سعدی | دیوان اشعار | رباعیات | رباعی شمارهٔ ۱۱۷

من خاک درش به دیده خواهم رفتن
ای خصم بگوی هرچه خواهی گفتن
چون پای مگس که در عسل سخت شود
چندانکه برانی نتواند رفتن

#سعدی | گنجور
📍@iipoem

یکی از اشخاصی که من خیلی محتواشو دوست دارم جناب اقای جرجندیه یه جوری دست این کلاه بردارارو رو میکنه ادم کیف میکنه

➖➖➖➖➖➖➖➖➖➖ 

🥷🏻 CHANNEL | GROUP

🔶 ایشون برنامه نویس فرانت اند که طرح های فانتزی زیبایی طراحی و کد نویسی می کند.

@TheRaymondDev

یک بلاگ فوق العاده راجع به اینکه دیپلوی کردن AI Agent ها توی محیط پروداکشن خیلی فرق داره با درست کردن یک دمو!
ساخت یه حلقه‌ی ساده برای ایجنت‌های مبتنی بر مدل‌های زبانی (LLM agents) خیلی آسونه. شاید با کمتر از ۲۰ خط کد! ولی این سادگی در واقع مشکلات پشت پردهٔ اجرای واقعی در محیط تولید (production) رو می‌پوشونه.
من خلاصه مقاله را میذارم ولی باید کامل خود مقاله بخونید.

- فاصله‌ی پنهان بین دمو و اجرا در عمل
۱. دمو مساوی نیست با محصول واقعی: شاید توی دمو همه‌چی خوب پیش بره، ولی توی محیط واقعی اتفاقاتی مثل:
-از کنترل خارج شدن ایجنت‌ها
- نشت اطلاعات توی context
- گیر کردن توی حلقه‌های بی‌پایان
- یا خراب شدن زنجیره ابزارها خیلی رایجه.
- همچنین، تصمیم‌گیری‌های معماری مثل مدیریت context، احراز هویت ابزارها یا ذخیره‌سازی state، اگر از اول درست انتخاب نشن، بعداً تغییر دادنشون کلی دردسر داره.

۲. دنیای کنفرانس‌ها با واقعیت فرق داره: شرکت‌های بزرگ ممکنه از زیرساخت‌های خاص خودشون برای اجرای چندایجنت به‌صورت موازی استفاده می‌کنن. ولی اکثر تیم‌ها کار رو ساده‌تر می‌گیرن:
- با Docker و GitHub Actions
- یا اجرای ایجنت‌ها روی AWS Lambda فقط برای صرفه‌جویی ماهانه ۱۰ دلار!

۳. کی اوضاع بهم می‌ریزه؟
وقتی لازم باشه ایجنت‌هاتون حافظه داشته باشن، بتونن بعد از قطع شدن ادامه بدن، یا با context طولانی کار کنن، همه چی پیچیده‌تر می‌شه. بعضی تیم‌ها تجربه‌شون رو اینطوری به اشتراک گذاشتن:
- ذخیره‌ی state توی دیتابیس (مثلاً PostgreSQL) برای بررسی و بازیابی
- استفاده از پردازش غیرهمزمان مثل job queue و webhook
- حذف فریم‌ورک‌های سنگین مثل LangChain و استفاده از FastAPI و کلاینت ساده OpenAI

- چی‌ها واقعاً مهمن؟
- زیرساخت موجود: همون جایی deploy کنید که تیم‌تون بلده (K8s، AWS Lambda، Docker و …)
- سرعت توسعه: گاهی اینکه زود به نتیجه برسید مهم‌تر از طراحی‌های پیچیده‌ست
- هزینه‌ها: حتی صرفه‌جویی‌های کوچیک هم مهمه، مخصوصاً برای استارتاپ‌ها

- نیازهای سازمانی برای ایجنت‌ها
- تناقض پلتفرم: شما دنبال قدرت یه پلتفرم کامل هستید (احراز هویت، حافظه، ارزیابی)، ولی در عین حال نمی‌خواید به یه vendor خاص وابسته بشید. استانداردهایی مثل MCP دارن کمک می‌کنن تا ابزارها باهم سازگار بشن.

- قابلیت اطمینان و مشاهده‌پذیری: ایجنت‌هاتون باید بعد از crash شدن بتونن ادامه بدن. باید ردگیری کامل، حافظه پایدار، و توانایی بررسی لاگ داشته باشید. Redis برای سرعت، PostgreSQL برای ماندگاری.

- مقیاس‌پذیری و انعطاف: وقتی کار جدی می‌شه، باید ایجنت‌ها بتونن از صفر تا هزاران اجرا در لحظه مقیاس پیدا کنن. اگه ایجنت‌هاتون کدنویسی انجام می‌دن، احتمالاً نیاز به sandbox برای امنیت و ایزوله کردن دارن.

- یکپارچه‌سازی و استانداردها: MCP داره نشون می‌ده که همه دنبال یه راه‌حل استاندارد برای اجرای ایجنت‌ها روی پلتفرم‌های مختلف هستن.

- نتیجه اخلاقی:
- ساده شروع کنید، نیازهای واقعی‌تون رو تخمین بزنید
- اول با deploy ساده مثل Docker یا Lambda برید جلو
- زود تست کنید، چون مشکلات واقعی فقط توی دنیای واقعی مشخص می‌شن
- کم‌کم پیچیدگی اضافه کنید. هر چیزی رو وقتی لازمه پیاده‌سازی کنید.

حتما کامل بخونید اگه ایجنت تو پرداکشن دیپلوی میکنید!
https://zenml.io/blog/the-agent-deployment-gap-why-your-llm-loop-isnt-production-ready-and-what-to-do-about-it

@DevTwitter | <Mehdi Allahyari/>

Monotonic Partial Order Reduction: An Optimal Symbolic Partial Order Reduction Technique

#paper #Aarti #CAV #2009
https://link.springer.com/content/pdf/10.1007/978-3-642-02658-4_31.pdf

امیرحسین نامی توی ارائه پرسید که آیا میشه non-determinism موجود در scheduling رو به SAT reduce کرد و حل کرد، من فراموش کردم که به این کار اشاره کنم. optimal نیست (برخلاف ادعای مقاله) و completeness نداره. ولی خودمم دارم میخونمش و ایده‌هایی دارم که بیارمش روی ConDpor.

لیفت یه برنامه تاکسی اینترنتیه و تو این مقاله توضیح میده که چطوری راننده ها و مسافرها رو بر اساس شرایط مختلف (مثلا مجاورت) به هم وصل می‌کنه. برای توضیحش از گراف و به شکل خاص از bipartite graph استفاده می‌کنه و به نظرم متن جالبی بود.

https://eng.lyft.com/solving-dispatch-in-a-ridesharing-problem-space-821d9606c3ff

🔶 به انگلیسی هم ترجمه شد.

@TheRaymondDev

🔶 بالاخره OBS برای ضبط دوره آموزشی تنظیم کردم.

هر ۱ دقیقه ۵ مگ خروجی میده...

یعنی ۳۰ دقیقه ضبط بشه حدود ۱۵۰ مگ خروجی میده...

@TheRaymondDev

خیلی از ماها دنبال LLM ای هستیم تا بتونه جواب های معتبری بده و جواب هاش رو از خودش درنیاورده باشه. برای حل این مسائل چه سرویس هایی مناسبه. یکی از راهکار ها استفاده از سرویس deep search در LLM های موجوده. یکی دیگه از راهکار ها استفاده ازسرویس های سرچ و اتصال آنها به LLM هست

Tavily
امکانات خوبی داره میتونید deep search به صورت advanced بگذارید تاجواب های بهتری بدهد حتی میتوان دامنه و تاریخ رو نیز مشخص کرد. کرالش برای سایت هایی که داینامیک بودن، نتونست دیتا مورد نظرم رو بخونه.
https://app.tavily.com/playground

Linkup
تقریبا شبیه tavily هست ولی منابع ای که در تست های من می آورد با tavily متفاوت بود. منابع معتبر و خوبی بود.
https://linkup.so

سرویس گوگل بود که در منابعی که جدول و عکس داشت نسبت به tavily به درستی خوب عمل نکرد.
https://ai.google.dev/gemini-api/docs/google-search

این مقایسه مدل ها در زمینهhallucination یا توهم مدل ها همون طور که میبینید مدل های گوگل عملکرد بهتری نسبت به openai داشتن:
https://github.com/vectara/hallucination-leaderboard?tab=readme-ov-file…


@DevTwitter | <Mari/>

این ویدیو جز آموزنده ترین تاثیر صورت بندی در حل مسئله ای بود که در زندگیم دیدم
https://youtu.be/1-zm2EvFr-g

🔥 مهم‌ترین اخبار هفته

🔹میز KDE Plasma 6.4.3: بروزرسانی جزئی با رفع باگ‌های جمع‌آوری شده طی دو هفته و بهبود ترجمه‌ها، مخصوص محیط دسکتاپ KDE

🔹برنامه Blender 4.5 LTS: نسخه‌ی پایدار جدید با بهبود پشتیبانی از Vulkan در اپلیکیشن گرافیک سه‌بعدی متن‌باز .

🔹برنامهVirtualBox 7.1.12: بهبود هماهنگی با هسته لینوکس ۶.۱۶ در میزبان و ماشین‌های مجازی لینوکسی .

🔹برنامهRescuezilla 2.6.1: سیستم بازیابی بر پایه Ubuntu 25.04، با ویژگی‌های موثر و رابط کاربری ساده .

🔹برنامهGStreamer 1.26.4: اضافه شدن پشتیبانی از timestamp نوع TAI در mp4mux و تغییرات جزئی دیگر .

🔹برنامهWireshark 4.4.8: به‌روزرسانی پروتکل‌ها و رفع باگ‌های ابزار تحلیل شبکه .

🔹برنامهLibreOffice 25.2.5: عرضه بسته‌ای با ۶۳ رفع اشکال برای مجموعه آفیس محبوب متن‌باز .

🔹برنامهCalibre 8.7: اضافه کردن قابلیت ساخت فایل‌های شماره‌گذاری صفحات برای کیندل‌های مبتنی بر MTP .

تو وبلاگش یه کتاب معرفی کرد. بعد از چند روز از کامنت‌هایی که گرفت مأیوس شد، چون اکثرا درباره این بودند که «میشه خلاصه‌ش رو بنویسی برامون؟». و همین رو سوژه مقاله بعدیش کرد و گفت «اینکه انقدر معتاد خلاصه‌سازی هستید که حتی رمان رو هم می‌خواهید در یکی دو پاراگراف قورت بدید، نشون‌دهنده یک روند در دوران ماست که اسمش رو فشرده‌پسندی میذارم و تا حد زیادی تحت تأثیر شبکه‌های اجتماعی و اینترنته! و این چیز خوبی نیست چون برای اینکه دانایی خودت رو افزایش بدی باید به گلاویز شدن با پیچیدگی‌ها تن بدی، و پیچیدگی خیلی وقت‌ها قابل فشرده‌سازی نیست، و اگه هم کسی فشرده‌ش کرد برات باعث میشه دچار این توهم بشی که میدانی در حالی که نمی‌دانی».
Anarconomy



@hagigcafe

توی ارائه امروز نقش کلیدی و مهم مسئله‌ی Reachability در Automated Verification رو دیدید. در گذشته من توی ۳ قسمت پستی نوشته بودم و کمی توضیح داده بودم این مسئله رو توی کانال. پست اول - پست دوم - پست سوم

منتهی یه نکته‌ای رو یادم رفت سر ارائه بگم اونم اینه که انقدری این مسئله مهمه که ما هر ساله یک کنفرانسی داریم به نام RP که مخفف Reachability Problem هستش. توی قسمت سوم بیشتر توضیح دادم

اسلاید‌های ارائه رو میتونید از اینجا دانلود کنید