توییتر را دوست دارم، جمله‌هایی که باید در 140 حرف جایشان داد و به سرعت برای دوستانی که تو رو دنبال می‌کنند منتشر می‌شود و پاسخ‌هایی که به همان شیوه‌ی خلاصه‌گویی به تو می‌دهند. زیبایی توییتر در سادگی و کاربردی بودنش است و در قدرت «لحظه‌نگاریش» که در همان لحظه هم پاسخ می‌گیری. یک گفتگوی چند جانبه‌ی لحظه‌ای که پیوسته ادامه دارد: در هر لحظه در سراسر جهان؛ هزاران نفر توییت می‌کنند. اما شواهد نشان می‌دهد که این گفتگوی زیبا محکوم به خاموشی است. توییتر اهداف جاه‌طلبانه‌ای دارد ولی به خاطر دست‌کم گرفتن پیچیدگی کار محکوم به خاموشی است؛ دست‌کم اگر در رویه‌‌ی فعلی‌اش تغییر اساسی ایجاد نکند.
دشواری توییتر چیست؟
سرورهای توییتر پاسخ‌گوی تعداد روزافزون کاربران «توییت‌کن» نیستند. روزی (و اخیرا ساعتی) نمی‌گذرد که دچار اختلال نشوند و زیر بار انبوه پیام‌ها کمر خم نکنند. مشکل اصلی توییتر را اگر بخواهم در یک جمله خلاصه کنم می‌شود:
پیام‌رسانی گروهی (Group Messaging) در مقیاس بزرگ کار بسیار پیچیده‌ای است.
توییتر یک سیستم پیام‌رسان بزرگ است (این‌جا را ببینید). هر پیامی که می‌نویسید به تعداد مشخصی کاربر به طور همزمان ارسال می‌شود. پاسخ‌های هر کدام از آن‌ها هم به همه‌ی کسانی که آن‌ها را فالو می‌کنند ارسال می‌شود. ارسال (و دریافت) تعداد زیادی پیام برای تعداد زیادی کاربر کار ساده‌ای نیست. در واقع اصلا گول ظاهر ساده‌ی توییتر را نخورید: کاری که توییتر انجام می‌دهد بسیار پیچیده و سنگین است.
عده‌ای اعتقاد دارند، به ازای هر کاربری که در توییتر اضافه می‌شود، حجم عملیات محاسباتی لازم به صورت نمایی (Exponential) افزایش می‌یابد. وضعیتی که رویارویی با آن دست‌کم با معماری فعلی توییتر به مرزهای «غیر ممکن» نزدیک شده است.
شبکه‌های اجتماعی هم مشکل مشابهی دارند؛ ولی معمولا با پیچیدگی کمتر، چرا که بیشتر پیام‌های کاربران به یک کاربر خاص ارسال می‌شود، برخلاف توییتر که در آن همه‌ی پیام‌ها برای همه‌ی مخاطبان یک کاربر یا یک گروه از پیش تعریف شده ارسال می‌شود. با این‌حال شبکه‌های اجتماعی هم سال‌ها دست به گریبان حل مشکل پیام‌رسانی گروهی بودند. راه‌حل برخورد با مساله‌ای چنین پیچیده، باید نوآورانه و متناسب با مقیاس کار باشد. کاری که مثلا گوگل در برخوردش با حجم عظیم اطلاعات و پردازش لحظه‌ای انجام داد.
هیچ ارزانی‌ای بی‌حکمت نیست
توییتر از چارچوب «روبی روی ریل» (RubyOnRails) استفاده می‌کند که اگر چه برای محصولات شبکه‌ای با تعداد کاربران محدود یا پیچیدگی کمتر مناسب است، احتمالا برای نرم‌افزار سنگین و پرمحاسبه‌ای مانند توییتر انتخاب بهینه‌ای نبوده است. «روبی روی ریل» به طراحان توییتر اجازه داد که محصول خود را خیلی زود و ارزان به بازار عرضه کنند، اما برای کاری در این مقیاس نمی‌تواند با معماری‌های مبتنی بر جاوا یا C رقابت کند. سرنوشت توییتر به ما یادآوری می‌کند که «هیچ ارزانی‌ای بی‌حکمت نیست».
چند روزی است که برای حل موقتی مشکل، تیم فنی توییتر سرویس پاسخ (Reply) را خاموش می‌کنند. این یک اشتباه بزرگ است و نه تنها راه حل نیست، بلکه کاربران را از توییتر به رقیب قدرتمند و تازه‌نفس‌اش فرندفید می‌راند. حل مشکل توییتر راه‌کار اساسی می‌طلبد.
توییتر محبوب‌ترین سرویس میکروبلاگینگ یا لحظه‌نگاری است. اما برای این‌که زنده بماند باید معماری خود را به طور زیربنایی عوض کند و برای این‌کار به مدیریت جذب سرمایه نیاز دارد. در بازار پر رقابت امروز، اگر توییتر نجنبد، چندی نخواهد گذشت که برای همیشه خاموش خواهد شد.
پی‌نوشت:
درباره‌ی بحث این‌که مشکل توییتر به چارچوب روبی‌روی‌ریل برمی‌گردد یا خیر این مطالب را ببینید: {4}، {5}، {6}
