چارچوب مصاحبه طراحی سیستم: طراحی کوتاه‌کننده URL و اپلیکیشن‌های چت

مصاحبه‌های طراحی سیستم می‌توانند ترسناک به نظر برسند، اما الگوی قابل پیش‌بینی‌ای دارند. موفقیت نه به دانستن همه فناوری‌ها، بلکه به ساختاردهی شفاف به تفکر شما بستگی دارد. این مقاله یک چارچوب محکم را ترسیم می‌کند که می‌توانید آن را روی مسائل کلاسیک مانند کوتاه‌کننده‌های URL و اپلیکیشن‌های چت بلادرنگ به کار ببرید تا بلوغ معماری و عمق دانش خود را نشان دهید.

گام ۱: شفاف‌سازی نیازمندی‌ها و محدوده

هرگز مستقیماً به معماری نپرید. با تعریف مرزهای مسئله شروع کنید. برای یک کوتاه‌کننده URL، بپرسید: آیا به تحلیل‌ها نیاز داریم؟ ترافیک مورد انتظار چقدر است؟ آیا زمان انقضای لینک حیاتی است؟ برای یک اپلیکیشن چت، شفاف کنید: آیا یک‌به‌یک است یا گروهی؟ آیا به پشتیبانی آفلاین یا رسیدهای خوانده‌شدن نیاز داریم؟ محدودیت‌های کمّی حیاتی هستند. فرض کنید کوتاه‌کننده URL باید ۱۰۰ میلیون نوشتار در روز و ۱ میلیارد خوانش در روز را مدیریت کند. برای اپلیکیشن چت، فرض کنید ۵۰۰,۰۰۰ کاربر فعال روزانه با میانگین ۵۰ پیام در کاربر وجود دارد.

گام ۲: طراحی معماری سطح بالا

اجزای اصلی را ترسیم کنید. هر دو سیستم معمولاً شامل کلاینت، باربالانس، سرورهای اپلیکیشن، لایه داده و احتمالاً یک کش هستند.

معماری کوتاه‌کننده URL

منطق اصلی ساده است: نگاشت یک URL طولانی به یک کد کوتاه منحصربه‌فرد. هنگام نوشتن، یک شناسه منحصربه‌فرد تولید و نگاشت ذخیره می‌شود. هنگام خوانش، شناسه جستجو و هدایت مجدد انجام می‌شود. یک تصمیم حیاتی، استراتژی تولید شناسه است. استفاده از خودافزایش دیتابیس ساده است اما می‌تواند گلوگاه شود. رویکرد بهتری استفاده از یک تولیدکننده شناسه توزیع‌شده یا هش است. کدگذاری base62 را برای حداکثرسازی تعداد URLهای کوتاه ممکن در محدودیت ۷ کاراکتری در نظر بگیرید.

// شبه‌کد برای تولید URL کوتاه
function generateShortCode(longUrl) {
    // گزینه ۱: دنباله دیتابیس
    id = db.get_next_id();
    
    // گزینه ۲: مبتنی بر هش (با بررسی برخورد)
    hash = md5(longUrl).substring(0, 7);
    if (db.exists(hash)) {
        handle_collision(hash);
    }
    
    base62_code = to_base62(id);
    return base62_code;
}

معماری اپلیکیشن چت

چت بلادرنگ است و به اتصالات WebSocket یا پلینگ طولانی نیاز دارد. معماری باید وضعیت‌های موقتی (وضعیت آنلاین) و وضعیت‌های ماندگار (پیام‌ها) را مدیریت کند. یک صف پیام (Kafka، RabbitMQ) برای جداسازی دریافت پیام از تحویل آن ضروری است. سرور اپلیکیشن نباید مستقیماً اتصالات WebSocket را به دیتابیس نگه دارد؛ به جای آن، باید پیام‌ها را برای دوام در یک انبار NoSQL (مانند Cassandra یا DynamoDB) ذخیره کند و از یک سرویس جداگانه برای ارسال بلادرنگ استفاده کند.

گام ۳: مدل داده و انتخاب ذخیره‌سازی

مدل‌های داده باید با الگوهای دسترسی مطابقت داشته باشند.

مدل داده کوتاه‌کننده URL

اگر نسبت خوانش/نوشتار متعادل باشد، یک دیتابیس رابطه‌ای (MySQL) اغلب برای جدول نگاشت کافی است، اما جستجو داغ‌ترین مسیر است. از Redis برای کش کردن کدهای کوتاه داغ استفاده کنید. ساختار جدول ساده است: short_code (کلید اصلی)، long_url، created_at، creator_id. پارتیشن‌بندی بر اساس هش short_code توزیع یکنواخت را در بین گره‌ها تضمین می‌کند.

مدل داده اپلیکیشن چت

پیام‌های چت فقط افزودنی هستند. یک انبار ستون‌باز مانند Cassandra برای نوشتارهای پرتراکم ایده‌آل است. جدول را طوری طراحی کنید که بازیابی کارآمد پیام‌های اخیر برای یک مکالمه را ممکن سازد.

CREATE TABLE messages (
    conversation_id uuid,
    message_timestamp timeuuid,
    sender_id uuid,
    content text,
    PRIMARY KEY (conversation_id, message_timestamp)
) WITH CLUSTERING ORDER BY (message_timestamp DESC);

گام ۴: مقیاس‌پذیری و گلوگاه‌ها

جایی که طراحی شما شکست می‌خورد را شناسایی کنید.

مقیاس‌پذیری کوتاه‌کننده‌های URL

خوانش‌ها معمولاً ۱۰ تا ۱۰۰ برابر بیشتر از نوشتارها رخ می‌دهند. کش اجباری است. یک کش چندلایه پیاده‌سازی کنید: L1 در حافظه (Caffeine) در سرور اپلیکیشن، L2 توزیع‌شده (Redis). برای کلیدهای داغ، از کش محلی برای کاهش تأخیر شبکه استفاده کنید. اگر تولیدکننده شناسه گلوگاه شود، به یک تولیدکننده دنباله توزیع‌شده بروید که محدوده‌های شناسه را به سرورهای اپلیکیشن از قبل تخصیص می‌دهد.

مقیاس‌پذیری اپلیکیشن‌های چت

گلوگاه لایه WebSocket است. سرورهای اپلیکیشن که اتصالات سوکت را نگه می‌دارند، حالت‌دار هستند. از یک لایه اتصال استفاده کنید که از مقیاس‌پذیری افقی پشتیبانی می‌کند، احتمالاً با یک باربالانس نشست چسبنده یا یک سرویس دروازه‌ای حالت‌دار. برای پخش پیام در چت‌های گروهی، از یک سیستم Pub/Sub (مانند Kafka) استفاده کنید که در آن هر عضو گروه به موضوع یا پارتیشن خود مشترک می‌شود. این اطمینان می‌دهد که هر کاربر پیام‌های خود را دریافت می‌کند بدون اینکه بقیه را مسدود کند.

گام ۵: مبادلات و موارد حاشیه‌ای

عمق خود را با بحث در مورد مبادلات نشان دهید. برای کوتاه‌کننده‌های URL، مبادله بین تضمین یکتایی و عملکرد را بحث کنید. یک هش ممکن است برخورد کند؛ یک دنباله یکتا است اما متمرکز. برای چت، مبادله بین یکپارچگی و در دسترس بودن را بحث کنید. در یک اپلیکیشن چت، از دست دادن یک پیام بد است، بنابراین دوام را اولویت قرار دهید. با این حال، برای به‌روزرسانی‌های حضور (آنلاین/آفلاین)، یکپارچگی قوی لازم نیست؛ یکپارچگی نهایی از طریق کش مبتنی بر TTL قابل قبول و کارآمدتر است.

نتیجه‌گیری

مصاحبه‌های طراحی سیستم درباره حل مسئله ساختاریافته است، نه حفظ کردن. با دنبال کردن این چارچوب—شفاف‌سازی نیازمندی‌ها، طراحی معماری سطح بالا، انتخاب مدل داده مناسب، شناسایی گلوگاه‌های مقیاس‌پذیری و بحث در مورد مبادلات—می‌توانید با اعتماد به نفس سؤالات طراحی پیچیده را مدیریت کنید. تمرین کنید که این روش‌شناسی را روی هر دو کوتاه‌کننده URL و اپلیکیشن‌های چت به کار ببرید، و شهود لازم برای مدیریت هر چالش طراحی سیستم را توسعه خواهید داد.