Engineering

So zeichnest du schnell ein Diagramm fürs System-Design-Interview

Im System-Design-Interview hast du vierzig Minuten, und die Hälfte davon gehört dem Diagramm. So zeichnest du eine saubere, skalierbare Architektur, ohne den Raum zu verlieren.

Ein System-Design-Interview ist kein Zeichentest, aber beim Zeichnen verlieren die meisten Leute still und leise. Du beginnst mit einem ordentlichen Kasten für den Client, und dreißig Minuten später ist das Board ein Dickicht aus gekreuzten Pfeilen, drei Dingen namens "Service" und einer Datenbank, die du zweimal gezeichnet hast. Der Interviewer kommt nicht mehr mit, und sobald er nicht mehr mitkommt, ist er auch nicht mehr überzeugt.

Die Lösung ist nicht, unter Druck besser zu zeichnen. Sie besteht darin, in einer festen, geübten Reihenfolge zu zeichnen, sodass sich das Bild von selbst aufbaut, während deine Aufmerksamkeit bei den Trade-offs bleibt, über die du sprichst. Hier ist die Reihenfolge, die funktioniert, und wie jeder Schritt Sekunden statt Minuten dauert.

Das Diagramm ist nicht das Ergebnis. Das Gespräch ist es.

Interviewer bewerten nicht deine Rechtecke. Sie beobachten, ob du eine vage Aufgabe nehmen, sie in Komponenten zerlegen und begründen kannst, was zuerst bricht. Das Diagramm sorgt dafür, dass dieses Gespräch nachvollziehbar bleibt: für euch beide, in Echtzeit. Das Ziel ist also ein Bild, das jederzeit lesbar ist, niemals ein Bild, das fertig ist. Wenn das Board in jedem Moment klar ist, kannst du dir erlauben, mit deinen Worten langsam und überlegt zu sein.

Daraus folgen zwei Regeln, bevor du irgendetwas zeichnest. Sprich, während du zeichnest, nie in Stille. Und zeichne nie neu; verschiebe und erweitere, was schon da ist. Beides wird viel einfacher, wenn das Tool deine Pfeile für dich ordentlich hält, und genau deshalb zeichnest du das auf einer echten Leinwand statt in einem geteilten Dokument.

Beginne mit dem Request-Pfad

Jedes Design hat ein Rückgrat: was mit einem Request passiert, von dem Moment an, in dem ein Nutzer ihn auslöst. Zeichne das zuerst, von links nach rechts, bevor du das Wort "Skalierung" sagst. Client, Edge, das, was antwortet, das, was sich erinnert. Fünf Kästen und vier Pfeile, und du hast schon etwas, worüber du sprechen kannst.

HTTPSRoutequerycache Client Load balancer+ CDN / TLS API-Servicestateless x N DB Cache
Zuerst das Rückgrat: ein Request, von links nach rechts. Alles andere im Interview ist eine Änderung an dieser Linie.

Beachte, dass hier noch nichts Raffiniertes passiert, und genau darum geht es. Du hast dem Interviewer ein gemeinsames Vokabular gegeben. Jetzt ist jede Skalierungsentscheidung eine kleine, sichtbare Änderung an einem Bild, das ihr beide schon versteht, statt einer neuen Zeichnung, die du von Grund auf erklären musst.

Skalierbare Architektur zeichnen: live, ein Engpass nach dem anderen

Der spannende Teil des Interviews ist, was du hinzufügst, wenn die Zahlen groß werden, und der Trick ist, es an der richtigen Stelle des Rückgrats hinzuzufügen und dabei zu sagen, warum. Du dekorierst nicht; du reagierst auf einen konkreten Druck. Geh den Request-Pfad entlang und frag dich, was zuerst umfällt.

  • Lesezugriffe dominieren? Setz Read Replicas hinter die Datenbank und einen Cache davor. Zeichne den Cache als Abzweig vom API-Kasten, nicht als neue Station auf der Hauptlinie.
  • Schreibzugriffe in Spitzen? Setz eine Queue hinter die API und einen Worker dahinter, damit die langsame Arbeit abseits des Request-Pfads passiert. Jetzt zeigt das Diagramm sync und async als zwei klar unterschiedliche Formen.
  • Eine Region reicht nicht? Leg einen Kasten um das ganze Rückgrat, beschrifte ihn als Region und klone ihn. Plötzlich haben Replikation und Failover einen Platz.
  • Eine Tabelle zu heiß? Teile den Datenbank-Kasten in Shards und sag ein Wort zum Shard Key. Diese eine Änderung trägt ein ganzes Gespräch.

Großartige System-Design-Diagramme werden nicht gezeichnet. Sie wachsen, eine sichtbare Entscheidung nach der anderen.

Halte es lesbar, während du sprichst

Boards werden zu Knäueln, weil Pfeile als gerade Linien durch alles gezogen werden, was im Weg ist. Auf einer echten Leinwand kannst du dich stattdessen auf das Tool verlassen. Nutze intelligente Verbinder, damit ein neuer Pfeil um bestehende Kästen herumführt statt quer hindurch, und das Bild bleibt sauber, auch wenn es sich füllt. Gruppiere zusammengehörige Teile (die Region, die Async-Spur, die Datenschicht) in beschriftete Container, damit der Interviewer die Struktur sieht, nicht nur die Einzelteile. Wenn du eine Komponente umbenennst, tu es einmal und lass jede Referenz folgen.

Nichts davon ist Pedanterie. Es geht darum, die Sekunden zurückzugewinnen, die du sonst damit verbringen würdest, dich für das Chaos zu entschuldigen, und sie stattdessen in die Antwort zu stecken.

Tipp. Bau dir einmal ein Starter-Board und nutze es bei jeder Übung wieder: Client, Load Balancer, zustandsloser Service, Cache, primäre Datenbank. Dupliziere es zu Beginn eines Probeinterviews, und du startest jede Session direkt beim spannenden Teil.

Übe die Reihenfolge, nicht das Bild

Die Aufgabe kannst du nicht vorhersagen, aber die Form deiner Antwort schon: zuerst das Rückgrat, dann die Engpässe in der Reihenfolge, in der sie zubeißen, dann eine Grenze um alles herum. Probe diese Abfolge ein Dutzend Mal auf derselben Leinwand, und sie wird zum Muskelgedächtnis, genau das, was du willst, wenn der Raum still und die Uhr laut ist. Die Kandidaten, die ruhig wirken, zeichnen nicht schneller. Sie zeichnen in einer Reihenfolge, die sie schon einmal gemacht haben.

Öffne eine leere Leinwand, zeichne das Rückgrat aus fünf Kästen und fang an, Druck hinzuzufügen. Beim dritten Übungsdurchlauf hält das Diagramm mit deinem Denken Schritt, statt dagegen anzukämpfen.

Übe dein nächstes System Design auf einer echten Leinwand

Zeichne den Request-Pfad, füge Replicas und Queues live hinzu und lass intelligente Verbinder das Board sauber halten, während du sprichst.

LetDraw kostenlos öffnen