چرا ما REST API را با Kafka Streams جایگزین کردیم و ۸۰٪ تأخیر را کاهش دادیم؟

شروع ماجرا: یک درخواست کند همه‌چیز را به‌هم ریخت

ما داشبوردی برای کاربران داشتیم. این داشبورد شامل اطلاعات پروفایل، تراکنش‌های اخیر، وضعیت پرداخت، هشدارها و تنظیمات امنیتی بود — همه در یک نما.

برای ساخت آن، در سمت سرور پنج درخواست REST داخلی اجرا می‌کردیم:

• دریافت اطلاعات پروفایل کاربر

• دریافت ۱۰ تراکنش اخیر

• دریافت وضعیت پرداخت

• دریافت وضعیت اعلان‌ها

• دریافت تنظیمات امنیتی

اوایل همه‌چیز خوب پیش می‌رفت...

اما با افزایش کاربران، حجم داده و ترافیک بالا رفت.

ناگهان هر بار که یک کاربر داشبورد را باز می‌کرد، لود آن تا ۱۲ ثانیه طول می‌کشید.

و وقتی فقط یکی از APIهای داخلی شکست می‌خورد، کل صفحه از کار می‌افتاد.

در همین زمان بود که از خودمان پرسیدیم:

تلاش‌های اولیه (که نتیجه ندادند)

ما همه راه‌ها را امتحان کردیم:

• اجرای موازی درخواست‌ها → هنوز کند بود

• منطق تلاش مجدد (Retry) → اوضاع بدتر شد

• کش‌کردن اطلاعات → کمی کمک کرد، اما داده‌ها قدیمی بودند

• افزایش تایم‌اوت → فقط مشکل را پنهان کرد، نه حل

در نهایت فهمیدیم که REST دیگر برای این کاربرد مناسب نیست.

ما در حال ساختن یک فرم نبودیم، بلکه در حال ساختن جریانی زنده از داده‌ها بودیم.

نقطه عطف: درخواست نکن، جریان بده!

یکی از اعضای تیم پیشنهادی داد:

اینجا بود که Kafka Streams وارد بازی شد.

ما قبلاً Kafka را برای سیستم‌های مبتنی بر رویداد استفاده می‌کردیم، اما هرگز از آن برای ایجاد یک نمای زنده و به‌روز از داده‌ها بین سرویس‌ها استفاده نکرده بودیم.

پس یک تست کوچک راه انداختیم...

<<لیست دوره‌های آکادمی JavaPro — از شروع جاوا تا ساخت میکروسرویس‌های پیشرفته با Spring Boot >>

چگونه از Kafka Streams استفاده کردیم؟

به‌جای درخواست‌های همزمان REST، این کارها را انجام دادیم:

• به رویدادهای کاربر، پرداخت و تراکنش در Kafka سابسکرایب کردیم

• با استفاده از Kafka Streams این رویدادها را به‌صورت بلادرنگ (Real-time) پردازش و با هم join کردیم

• جدیدترین داده‌ها را در یک State Store (ذخیره‌ساز وضعیت در حافظه) نگه داشتیم

• این نمای به‌روز را از طریق یک REST سبک یا WebSocket به کاربر ارائه کردیم

نتیجه: وقتی کاربر داشبورد را باز می‌کند، داده‌ها از قبل آماده‌اند.

بدون زنجیره API، بدون انتظار

تغییرات واقعی: چه اتفاقی افتاد؟

قبل از Kafka Streams:

• تأخیر داشبورد: ۸ تا ۱۲ ثانیه

• خطا از ۵ سرویس داخلی

• لاگ‌ها پر از تلاش مجدد و تایم‌اوت

بعد از Kafka Streams:

• داشبورد در کمتر از ۲ ثانیه بارگذاری می‌شود

• خطاها و لاگ‌ها به‌شدت کاهش یافته

• سیستم حتی در ترافیک بالا پایدار مانده است

مشکلاتی که با آن‌ها روبه‌رو شدیم (و حل‌شان کردیم)

1. State Store خالی بود

هیچ داده‌ای نمایش داده نمی‌شد.

راه‌حل: به پارتیشن‌های درست Kafka سابسکرایب نشده بودیم. پیکربندی تاپیک‌ها را اصلاح کردیم و از KTable join به‌جای KStream استفاده کردیم.

2. کرش در برخورد با داده‌های ناقص

بعضی پیام‌ها فیلدهای موردنیاز را نداشتند و Kafka Streams کرش می‌کرد.

راه‌حل: فیلترهای ایمن با .filter() و بررسی مقادیر null قبل از پردازش اضافه کردیم.

3. تأخیر هنگام استقرار مجدد

با هر بار دیپلوی، استریم‌ها موقتاً متوقف می‌شدند.

راه‌حل: از شناسه‌های ثابت برای گروه مصرف‌کننده (consumer group IDs) استفاده کردیم و تعداد دیپلوی‌های غیرضروری را کاهش دادیم.

4. یادگیری Kafka Streams برای تیم زمان‌بر بود

مفاهیمی مانند KTable، join و window برای تیم ما جدید بودند.

راه‌حل: فقط با یک مورد استفاده شروع کردیم، مستندسازی داخلی انجام دادیم و یک پروژه‌ی مرجع کوچک برای اعضای جدید ساختیم.

درس‌هایی که گرفتیم

• ✔ REST APIها عالی‌اند — اما نه برای تجمیع بلادرنگ داده‌ها

• ✔ اگر سرویس شما به ۳ تا ۵ API داخلی وابسته است، شما در حال ساختن گلوگاه عملکرد هستید

• ✔ Kafka Streams نمایی بلادرنگ، همیشه تازه و سریع به شما می‌دهد

• ✔ State Store مانند یک پایگاه داده درون حافظه‌ای سبک است — مناسب برای داشبوردهای سنگین با خواندن زیاد

• ✔ لازم نیست همه‌چیز را بازسازی کنید — ما فقط یک جریان پرتاخیر را جایگزین کردیم و نتیجه چشم‌گیر بود

سخن پایانی

ما کل بک‌اند را از نو نساختیم.

ما فقط یک جریان با تأخیر بالا را با Kafka Streams جایگزین کردیم و نتیجه فوق‌العاده‌ای گرفتیم:

• ۸۰٪ کاهش تأخیر

• حذف خطاهای API زنجیره‌ای

• تجربه کاربری سریع‌تر

• تیمی که کمتر درگیر پشتیبانی و رفع اشکال شد

اگر شما هم با APIهای کند داخلی دست‌وپنجه نرم می‌کنید یا می‌خواهید سیستم‌هایی با تقریب به زمان واقعی بسازید، Kafka Streams می‌تواند همان تغییری باشد که نیاز دارید.

با یک جریان کوچک شروع کنید. برای ما جواب داد — شاید برای شما هم جواب بدهد.

منبع: این مقاله از سایت Medium و نوشته‌ی Serxan Hamzayev گرفته شده است.