Bit.ly מטפלת ביותר מ-600 מיליון redirects בחודש. כל redirect חייב להסתיים בפחות מ-10ms - כי HTTP redirects הם בcritical path של חוויית ה-user. אם bit.ly איטי, כל לינק ב-Twitter וכל מייל שיווקי עם shortened URL - איטי. זו השאלה הנפוצה ביותר בראיונות System Design לרמת Entry, ורוב המועמדים עונים עליה לא נכון - כי הם קופצים ישר ל"נשתמש בDatabase" לפני שהם מבינים מה המשמעות של 10 מיליארד קליקים ביום.
URL Shortener נראה פשוט - hash → lookup → redirect. אבל בscale אמיתי, הבעיות מתחילות: איך מבטיחים ייחודיות בלי single-point bottleneck? איך מגישים 116,000 redirects בשנייה בפחות מ-10ms? מה קורה ל-URL שמישהו הולך viral עם 50 מיליון קליקים ביום? כל אחת מהשאלות האלה מוליכה להחלטת ארכיטקטורה שונה.
בשיעור הזה נעבור על כל שלב בתכנון URL Shortener, מRequirements ועד Scaling, עם ההחלטות הטכניות הנכונות - ולמה כל אחת מהן הגיונית.
מה שמעניין בURL Shortener כשאלת ראיון הוא שהיא deceitfully simple. כל Senior engineer שפוגש אותה בראיון צריך לעצור ולא לגשת ל"solution" מיידי. השאלה שנראית פשוטה - "קצר URLs" - מחביאה בתוכה בחירות שמשפיעות על כל ה-architecture: Analytics בzמן אמת או batch? 301 או 302? custom domains? expiration? geolocation routing? כל שאלת clarification שתשאלו תחשוף requirement שמשנה ה-design. candidate שמבין את זה ומוציא 5 דקות לשאלות לפני שמצייר כלום - מראה system thinking ש-candidate שקופץ ל-Redis מיד לא מראה.