التعمّق في التصميم: URL Shortener + Pastebin
في هذا الدرس نتدرّب على الإجابة عن سؤال مقابلة كلاسيكي: بناء "URL shortener" (خدمة تأخذ عنوان ويب طويلًا وتعيد عنوانًا قصيرًا، مثل bit.ly). نتحدّث بعبارات بسيطة عن كيفية استقبال الخدمة للطلبات (API — الطريقة التي تتحدّث بها البرامج فيما بينها)، وكيف نخزّن البيانات (الـ schema — شكل الجدول في قاعدة ا
System Design (التخطيط لكيفية بناء برمجيات كبيرة تعمل بكفاءة) يشبه تخطيط مدينة: طرق تُحرّك حركة المرور، ومخازن للتخزين، وإشارات مرور تُدير الحِمل، وفِرق صيانة تُصلح الأعطال — بحيث تظل المدينة تعمل بسلاسة حتى في أوقات الذروة الأكثر ازدحامًا.
- التعمّق الكلاسيكي
- السؤال الكلاسيكي الذي نتدرّب عليه في هذا الدرس: تصميم "URL shortener" مثل bit.ly. نمرّ على كيفية وصول الطلبات (الـ API)، وكيف تُخزَّن البيانات (الـ schema — شكل الجدول)، وكيف يُنشأ الرمز القصير (ID generation)، وكيف نُسرّع الأمور بذاكرة سريعة (cache)، وكيف ننمو لخدمة عدد كبير من المستخدمين (scale).
- Trade-off
- الـ trade-off هو اختيار مقصود بين أمرين جيدين حين لا يمكنك الحصول على كليهما بالكامل — مثل الاختيار بين السريع والرخيص. هناك دائمًا ثمن، وفي المقابلة تقوله بصوت عالٍ للمُقابِل.
- مقياس تشغيلي
- رقم يُظهر ما إذا كان القرار يعمل فعلًا لدى المستخدمين الحقيقيين (في الـ production — المنظومة الحيّة). على سبيل المثال: latency (كم من الوقت يستغرق الحصول على إجابة)، error rate (نسبة الطلبات التي تفشل)، queue lag (كم من العمل تراكم في الطابور بانتظار المعالجة)، أو cache hit ratio (كم مرة كانت الذاكرة السريعة تعرف الإجابة بالفعل).
