Comment j'apprends le system design

Le contenu de system design est partout en ce moment, et la plupart suppose que vous avez déjà fait tourner quelque chose en production et que vous l'avez vu casser. Cette expérience est vraiment utile. Ce n'est pas non plus la seule façon d'y entrer, et attendre de l'avoir avant de toucher au sujet reviendrait à ne jamais commencer.

Donc je construis les systèmes que les vidéos expliquent, au lieu de me contenter de les regarder.

Regarder seul n'enseigne pas le system design

Je peux regarder une vidéo expliquer les load balancers, le caching, et les choix de database, et hocher la tête tout du long. Ce n'est pas la même chose que comprendre pourquoi un choix précis compte pour un problème précis.

Le URL shortener dont j'ai parlé vient directement de là. Une vidéo de system design a parcouru l'architecture, et au lieu de juste la regarder, j'ai construit la chose : trois copies de l'app derrière un load balancer, un database choisi pour le pattern d'accès, un cache ajouté sans toucher au reste du code.

Ce que le construire m'a appris que le regarder n'a pas appris

En regardant la vidéo, « ajouter un cache » sonne comme une seule étape évidente. En le construisant, j'ai dû décider où le cache vivait dans le code, ce qui se passait sur un miss, et combien de temps une entrée devait survivre avant de devenir stale.

Aucune de ces décisions n'est dans le diagramme. Elles n'apparaissent que quand vous écrivez le code et tombez sur les questions que le diagramme a sautées, et se tromper une fois enseigne plus que se le faire expliquer dix fois.

Les petits systèmes ont les mêmes formes

L'autre chose que je continue à remarquer : les problèmes n'ont pas besoin d'une échelle de production pour être réels. Deux requests qui touchent la même ligne, c'est un problème de concurrence que le système ait dix utilisateurs ou dix millions. Une query lente est lente à n'importe quelle taille. Décider qu'un cache et un database peuvent être en désaccord, c'est la même décision dans les deux cas.

L'échelle change combien coûte une erreur. Elle ne change pas la forme de l'erreur, ce qui est la partie qui vaut la peine d'être apprise en premier.

Où j'en suis avec ça

Je n'essaie pas d'apprendre tous les patterns d'un coup. Chaque projet ramasse un ou deux nouveaux concepts, load balancing et caching cette fois, et laisse le reste pour ce que je construirai ensuite.

C'est plus lent que de parcourir un cours complet en une seule fois, et c'est la seule approche que j'aie trouvée où les concepts collent au lieu de devenir du vocabulaire que je reconnais sans vraiment le comprendre.