‏Stream Processing همیشه راه‌حل نیست

کای وینر (Kai Waehner) سال‌ها تو Confluent روی event streaming کار کرده و الان Global Field CTO شرکت Kestra ست. اون می‌گه پردازش جریانی (Stream Processing، یعنی محاسبه‌ی مداوم روی رویدادهایی که پشت سر هم و بدون توقف میان) یکی از باارزش‌ترین قابلیت‌های معماری امروزیه، ولی بیشتر از حد لازم و جای اشتباه به کار گرفته می‌شه. به گفته‌ی اون، تشخیص اینکه کِی نباید ازش استفاده کرد، سخت‌تر از تشخیص اینه که کِی باید استفاده کرد.

دو نمونه‌ی واقعی این حرفو نشون می‌دن. Confluent Control Center، ابزار مدیریت و مانیتورینگ Confluent، سال‌ها روی Kafka Streams کار می‌کرد و استارتاپش بین ۱۵ تا ۵۰ دقیقه طول می‌کشید؛ بعد از مهاجرت به Prometheus، این عدد به حدود یه دقیقه رسید و تعداد پارتیشن‌های پشتیبانی‌شده از ۱۲۰ هزار به ۴۰۰ هزار تا رفت بالا. Kestra، پلتفرم اورکستریشن متن‌باز، تو نسخه‌ی 2.0 اش Kafka Streams رو کلاً از هسته‌ی خودش حذف کرد و لایه‌ی پیام‌رسانیش رو رو صف‌های ساده مثل Redis، AMQP، JDBC و Kafka بازسازی کرد.

نویسنده سه الگوی معماری رو از هم جدا می‌کنه: پردازش جریانی که مداومه و با ورود داده شروع می‌شه، کوئری دیتابیس که pull-based ـه و یه نفر یه سوال مشخص می‌پرسه، و فراخوانی API که درخواست/پاسخه. مشکل اینجاست که موتورهای استریم مثل Kafka Streams و Flink، state رو به‌صورت derived (مشتق‌شده) نگه می‌دارن، نه state of record؛ یعنی نمی‌شه مستقیم کوئری یا دستی اصلاحش کرد، و اگه خراب بشه، تنها راه یه rebuild کامله که تا وقتی تموم نشه سرویس در دسترس نیست.

نویسنده شش نشونه رو مطرح می‌کنه که یعنی وقتشه سراغ استریم پردازش نریم: نیاز به تاخیر خیلی کم یا اینکه اصلاً تاخیر مهم نیست، تعامل از نوع درخواست/پاسخ، وقتی خود state محصوله نه یه واسطه، وقتی سرعت ری‌استارت مهمه ولی state بزرگه، وقتی کار به lock یا isolation نیاز داره، و وقتی فقط چندتا آدم تو تیم می‌تونن اون سیستمو نگه دارن. به گفته‌ی اون Kafka همچنان انتخاب خوبیه برای backbone پیام‌رسانی، فقط لازم نیست هر معماری روش یه فریم‌ورک پردازش جریانی هم سوار بشه.

نکات کلیدی:

• Confluent Control Center: زمان استارتاپ از ۱۵ تا ۵۰ دقیقه به حدود ۱ دقیقه، پارتیشن‌های پشتیبانی‌شده از ۱۲۰ هزار به ۴۰۰ هزار
• Kestra 2.0 پشتیبانی از Kafka Streams رو از هسته‌ش برداشت و رو صف‌های Redis، AMQP، JDBC و Kafka بازسازی شد
• سه الگوی جدا از هم: پردازش جریانی (مداوم)، کوئری دیتابیس (pull-based)، فراخوانی API (درخواست/پاسخ)
• شش نشونه‌ی انتخاب اشتباه: تاخیر نامناسب، الگوی درخواست/پاسخ، state به‌عنوان محصول، rebuild کند، نیاز به lock، و کمبود نیروی متخصص