Deep Dive de conception : URL Shortener + Pastebin

Dans cette leçon, on s'entraîne à répondre en entretien à une question classique : construire un « raccourcisseur d'URL » (un service qui prend une adresse longue et renvoie une adresse courte, comme bit.ly). On va parler simplement de la façon dont le service reçoit les requêtes (API — la façon don

System Design (planifier comment construire un grand logiciel qui fonctionne) c'est comme planifier une ville : des routes qui font circuler le trafic, des entrepôts pour le stockage, des feux qui gèrent la charge, et des équipes de maintenance qui réparent les problèmes — pour que la ville continue de bien fonctionner même aux heures de pointe les plus chargées.

Deep Dive classique: La question classique qu'on pratique dans cette leçon : concevoir un « raccourcisseur d'URL » comme bit.ly. On passe en revue comment les requêtes arrivent (API), comment les données sont stockées (schema — la structure de la table), comment le code court est créé (ID generation), comment on accélère avec une mémoire rapide (cache), et comment on grandit pour des millions d'utilisateurs (scale).
Trade-off: Un trade-off, c'est un choix délibéré entre deux bonnes choses quand on ne peut pas avoir pleinement les deux — comme choisir entre rapide et pas cher. Il y a toujours un prix, et en entretien on le dit à voix haute à la personne qui interviewe.
Métrique opérationnelle: Un nombre qui montre si la décision fonctionne vraiment pour les utilisateurs réels (en production — le système en direct). Par exemple : latency (le temps que ça prend pour obtenir une réponse), error rate (la part des requêtes qui échouent), queue lag (la quantité de travail qui s'accumule en attente dans la file), ou cache hit ratio (la fréquence à laquelle la mémoire rapide avait déjà la réponse).