Frontend-Systemdesign im Interview: Vom vagen Prompt zum klaren Plan

Frontend-Systemdesign-Interviews wirken oft überwältigend. Bei „Entwirf ein gemeinsames Aufgabenboard“ denkt man sofort an React, WebSockets, Caching, APIs und Performance. Der bessere Start ist einfacher: Erst klären, was Nutzer erreichen müssen; danach Technik auswählen.

Beim Produkt beginnen, nicht bei Bibliotheken

Fragen Sie: Können Nutzer Aufgaben erstellen, bearbeiten und verschieben? Ist das Board geteilt? Müssen Änderungen sofort sichtbar sein? Gehören Anhänge oder Offline-Arbeit zum Umfang?

Nennen Sie eine Annahme: Ich entwerfe ein Web-Aufgabenboard für angemeldete Teammitglieder. Sie sehen Spalten, erstellen und verschieben Aufgaben und erhalten Änderungen anderer Personen, solange das Board geöffnet ist. Anhänge und Offline-Bearbeitung sind nicht Teil des Umfangs.

So wird aus „Entwirf Jira“ ein lösbares Problem.

Funktionale Anforderungen und Qualitätsanforderungen

Funktionale Anforderungen beschreiben Verhalten: Board ansehen, Aufgabe verschieben, filtern und Änderungen sehen. Latenz, Barrierefreiheit, Zuverlässigkeit und Skalierung sind Qualitätsanforderungen; sie beeinflussen die Architektur.

Beim Verschieben einer Aufgabe reagiert die Oberfläche sofort, der Client sendet die Mutation, der Server bestätigt den kanonischen Zustand und andere Nutzer erhalten ein Ereignis. Bei Fehlern wird zurückgesetzt und eine verständliche Meldung gezeigt.

Datenmodell und API aus Flüssen ableiten

Der Client benötigt eine Aufgaben-ID, Spalte, Position und Version. Ein Update-Vertrag enthält etwa columnId, position und version. Der Server liefert die endgültige Aufgabe mit neuer Version zurück. Bei parallelen Änderungen nennen Sie eine Regel, etwa Last-Write-Wins oder Ablehnung einer veralteten Version mit Aktualisierung.

State nach Eigentümer und Lebensdauer wählen

Menüs, Drag-Vorschau und Formularwerte sind lokaler UI-State. Filter und ausgewähltes Board gehören in die URL. Serverdaten wie Boards und Aufgaben gehören in einen Query-Cache. Echtzeitereignisse aktualisieren oder invalidieren die betroffene Cache-Entität statt eine zweite dauerhafte Kopie zu erzeugen.

Realtime und optimistische Updates

Bei gelegentlichen Updates reicht Polling. Für serverseitige Einweg-Updates passen Server-Sent Events. Presence, Tippen oder bidirektionale Zusammenarbeit können WebSockets rechtfertigen. Beginnen Sie mit der erforderlichen Aktualität, nicht mit dem Namen der Technologie.

Für optimistische Updates speichern Sie einen Snapshot, aktualisieren die UI lokal, senden die Mutation und stellen den Snapshot bei Fehlern wieder her. Ein gutes Design erklärt den Fehlerpfad genauso wie den Erfolgsfall.

Frontend-Risiken nicht vergessen

• Lange Listen virtualisieren.
• Drag-and-drop per Tastatur und Screenreader zugänglich machen.
• Lade-, Leer-, Berechtigungs- und Wiederholungszustände zeigen.
• Stabile IDs statt Array-Indizes verwenden.
• Langsame Interaktionen und fehlgeschlagene Mutationen beobachten, ohne sensible Inhalte zu loggen.

Antwortvorlage

1. Nutzer, Plattform und wichtige Flüsse klären.
2. Umfang und Ausschlüsse nennen.
3. Funktionale Anforderungen auflisten.
4. Nutzerflüsse beschreiben.
5. Datenmodell und API ableiten.
6. State nach Eigentümer und Lebensdauer trennen.
7. Performance, Barrierefreiheit, Zuverlässigkeit und Sicherheit behandeln.
8. Trade-offs und nächste Schritte erklären.

Fazit

Frontend-Systemdesign ist kein Wettbewerb der Bibliotheken. Beginnen Sie mit dem Ziel des Nutzers. Danach sind State, API, Rendering und Realtime-Entscheidungen nachvollziehbar begründet.