از CQRS تا یک سامانه حافظهمحور : داستان بازطراحی Tudum در نتفلیکس
الگوی #CQRS و معماریهای event-driven ابزارهای قدرتمندی برای مقیاسپذیری هستند. اما وقتی تأخیر بین «نوشتن» و «نمایش تغییر» زیاد شود، بهخصوص برای سناریوهای real-time مثل preview محتوا، همین الگوها میتوانند به گلوگاه تبدیل شوند.
📌 داستان Tudum (وبسایت طرفداران نتفلیکس) دقیقاً ناظر به همین مساله است.
⚡️ معماری اولیه: #CQRS + #Kafka + #Cassandra
نتفلیکس وبسایت طرفداران Tudum را در ۲۰۲۱ راهاندازی کرد تا محتوای جانبی مرتبط با برنامهها را به کاربران ارائه دهد و ویراستاران بتوانند تغییرات را پیشنمایش کنند.
دادهها ابتدا از CMS به سرویس ingestion میرفت، پردازش و روی #Kafka منتشر میشد، سپس در #Cassandra ذخیره و با near cache سریعتر به سرویس ساخت صفحات میرسید تا صفحات HTML برای کاربران ساخته و نمایش داده شوند. مسیر انتشار و نمایش دادهها جدا شد تا مقیاسپذیری بهتر شود، اما مشکل تأخیر cache همچنان باقی بود.
⚡️مزایا؟ تفکیک write و read و امکان scale مستقل.
⚠️ مشکل؟ ⏳ تغییرات محتوا در CMS با تأخیر زیاد روی سایت دیده میشد.
🔍 دلیل اصلی این تاخیر طبق گزارش نتفلیکس:
🔹کش با یک چرخهی refresh بهروزرسانی میشد.
🔹مثلاً اگر ۶۰ کلید داشتی و هر ثانیه یکی refresh میشد، تغییرات حداقل ۶۰ ثانیه بعد قابل مشاهده بود.
🔹با رشد محتوا، این زمان حتی به چند ده ثانیه میرسید.
🔹 برای نویسندگان و ویراستاران، این یعنی تجربهی preview عملاً بیفایده بود.
🚀 بازطراحی: RAW Hollow بهجای Kafka و Cassandra
به جای وصلهپینه روی کش یا افزایش سرعت Kafka، تیم نتفلیکس یک مسیر جدید انتخاب کرد: جایگزینی کل CQRS pipeline با یک دیتابیس in-memory به نام RAW Hollow.
آدرس پروژه : https://hollow.how
ویژگیها:
🔰کل dataset در حافظهی هر process ذخیره میشود → latency بسیار پایین.
🔰پشتیبانی از strong read-after-write consistency → تغییرات بلافاصله قابل مشاهدهاند.
🔰فشردهسازی Hollow حجم داده را تا ۲۵٪ نسخهی اصلی کاهش میدهد → کل داده جا میشود.
🔰معماری سادهتر: حذف Kafka، Cassandra و cache → کمتر شدن لایهها = کمتر شدن delay.
📊 نتایج برای Tudum
✨تأخیر در نمایش تغییرات: از چند ده ثانیه → به چند ثانیه.
✨زمان ساخت صفحه: از ~۱.۴s → به ~۰.۴s.
✨تجربهی preview برای نویسندگان روان شد.
✨معماری تمیزتر و بدون گرههای زائد.
💬 واکنشها در Hacker News و Reddit
انتشار این تجربه بحثهای زیادی ایجاد کرد:
🎯بعضی گفتند مشکل صرفاً cache invalidation بود و میشد سادهتر حل کرد.
🎯عدهای این تغییر را over-engineering دانستند برای سایتی شبیه یک بلاگ.
🎯گروهی دیگر تأکید داشتند که با مقیاس و نیاز به personalization نتفلیکس، این تصمیم منطقی است.
🎯برخی هم انتقاد کردند که مسئلهی کوچک به شکل یک چالش بزرگ بیان شده است.
🔑 جمعبندی:
پیچیدگی تکنیکی همیشه کارآمد نیست؛ Tudum نشان داد که حذف لایههای اضافی و نگهداری دادهها در حافظه میتواند تجربهی کاربری سریعتر و واقعیتری فراهم کند. انتخاب معماری همواره یک trade-off بین سرعت و سازگاری است، و در این مورد نتفلیکس سرعت را در اولویت گذاشت.
مدرسه مهندسی داده سپهرام : @sepahram_school
مقاله اصلی : https://www.infoq.com/news/2025/08/netflix-tudum-cqrs-raw-hollow
الگوی #CQRS و معماریهای event-driven ابزارهای قدرتمندی برای مقیاسپذیری هستند. اما وقتی تأخیر بین «نوشتن» و «نمایش تغییر» زیاد شود، بهخصوص برای سناریوهای real-time مثل preview محتوا، همین الگوها میتوانند به گلوگاه تبدیل شوند.
📌 داستان Tudum (وبسایت طرفداران نتفلیکس) دقیقاً ناظر به همین مساله است.
⚡️ معماری اولیه: #CQRS + #Kafka + #Cassandra
نتفلیکس وبسایت طرفداران Tudum را در ۲۰۲۱ راهاندازی کرد تا محتوای جانبی مرتبط با برنامهها را به کاربران ارائه دهد و ویراستاران بتوانند تغییرات را پیشنمایش کنند.
دادهها ابتدا از CMS به سرویس ingestion میرفت، پردازش و روی #Kafka منتشر میشد، سپس در #Cassandra ذخیره و با near cache سریعتر به سرویس ساخت صفحات میرسید تا صفحات HTML برای کاربران ساخته و نمایش داده شوند. مسیر انتشار و نمایش دادهها جدا شد تا مقیاسپذیری بهتر شود، اما مشکل تأخیر cache همچنان باقی بود.
⚡️مزایا؟ تفکیک write و read و امکان scale مستقل.
⚠️ مشکل؟ ⏳ تغییرات محتوا در CMS با تأخیر زیاد روی سایت دیده میشد.
🔍 دلیل اصلی این تاخیر طبق گزارش نتفلیکس:
🔹کش با یک چرخهی refresh بهروزرسانی میشد.
🔹مثلاً اگر ۶۰ کلید داشتی و هر ثانیه یکی refresh میشد، تغییرات حداقل ۶۰ ثانیه بعد قابل مشاهده بود.
🔹با رشد محتوا، این زمان حتی به چند ده ثانیه میرسید.
🔹 برای نویسندگان و ویراستاران، این یعنی تجربهی preview عملاً بیفایده بود.
🚀 بازطراحی: RAW Hollow بهجای Kafka و Cassandra
به جای وصلهپینه روی کش یا افزایش سرعت Kafka، تیم نتفلیکس یک مسیر جدید انتخاب کرد: جایگزینی کل CQRS pipeline با یک دیتابیس in-memory به نام RAW Hollow.
آدرس پروژه : https://hollow.how
ویژگیها:
🔰کل dataset در حافظهی هر process ذخیره میشود → latency بسیار پایین.
🔰پشتیبانی از strong read-after-write consistency → تغییرات بلافاصله قابل مشاهدهاند.
🔰فشردهسازی Hollow حجم داده را تا ۲۵٪ نسخهی اصلی کاهش میدهد → کل داده جا میشود.
🔰معماری سادهتر: حذف Kafka، Cassandra و cache → کمتر شدن لایهها = کمتر شدن delay.
📊 نتایج برای Tudum
✨تأخیر در نمایش تغییرات: از چند ده ثانیه → به چند ثانیه.
✨زمان ساخت صفحه: از ~۱.۴s → به ~۰.۴s.
✨تجربهی preview برای نویسندگان روان شد.
✨معماری تمیزتر و بدون گرههای زائد.
💬 واکنشها در Hacker News و Reddit
انتشار این تجربه بحثهای زیادی ایجاد کرد:
🎯بعضی گفتند مشکل صرفاً cache invalidation بود و میشد سادهتر حل کرد.
🎯عدهای این تغییر را over-engineering دانستند برای سایتی شبیه یک بلاگ.
🎯گروهی دیگر تأکید داشتند که با مقیاس و نیاز به personalization نتفلیکس، این تصمیم منطقی است.
🎯برخی هم انتقاد کردند که مسئلهی کوچک به شکل یک چالش بزرگ بیان شده است.
🔑 جمعبندی:
پیچیدگی تکنیکی همیشه کارآمد نیست؛ Tudum نشان داد که حذف لایههای اضافی و نگهداری دادهها در حافظه میتواند تجربهی کاربری سریعتر و واقعیتری فراهم کند. انتخاب معماری همواره یک trade-off بین سرعت و سازگاری است، و در این مورد نتفلیکس سرعت را در اولویت گذاشت.
مدرسه مهندسی داده سپهرام : @sepahram_school
مقاله اصلی : https://www.infoq.com/news/2025/08/netflix-tudum-cqrs-raw-hollow
👍5