Backend-Entwickler Interviewfragen & Antworten

Beispielantwort

Unsere API lieferte sporadisch 500-Fehler, rund 5 % der Anfragen waren betroffen, aber nur in Stoßzeiten. Die Fehler-Logs zeigten Timeouts bei Datenbankverbindungen, obwohl CPU und Arbeitsspeicher der Datenbank unauffällig waren. Ich ergänzte ein Monitoring für den Connection-Pool und stellte fest, dass wir unser Limit von 20 Verbindungen ausschöpften. Die Ursache: Ein neues Feature öffnete eine Datenbanktransaktion, führte innerhalb dieser Transaktion einen HTTP-Aufruf an einen externen Dienst durch, und dieser Dienst antwortete gelegentlich erst nach 30 oder mehr Sekunden. Dadurch blieb die Datenbankverbindung über die gesamte Wartezeit blockiert. Ich löste das Problem, indem ich den HTTP-Aufruf außerhalb der Transaktion verlagerte und die Verbindung erst für den eigentlichen Schreibvorgang öffnete. Zusätzlich erhöhte ich die Poolgröße auf 50 als Puffer und richtete Warnmeldungen für die Auslastung des Connection-Pools ein. Die 500-Fehlerrate sank sofort auf null.

Beispielantwort

Ich entwarf eine Partner-Integrations-API, die 15 externe Unternehmen nutzen sollten, um Produktdaten mit unserer Plattform zu synchronisieren. Bevor ich eine einzige Zeile Code schrieb, führte ich Gespräche mit 5 potenziellen API-Nutzern, um ihre Integrationsmuster zu verstehen. Dabei erfuhr ich, dass sie Batch-Operationen benötigten (nicht nur einzelne CRUD-Aufrufe) und Webhooks für Echtzeit-Updates wünschten. Ich gestaltete die API mit einheitlichen Benennungskonventionen, Paginierung, Filterung und aussagekräftigen Fehlerantworten mit konkreten Hinweisen. Nicht nur '400 Bad Request', sondern '400: Das Preisfeld muss eine positive Zahl sein. Empfangen: -5.99.' Ich generierte OpenAPI-Dokumentation aus dem Code, erstellte eine Sandbox-Umgebung mit Testdaten und schrieb eine Kurzanleitung mit Beispielen in Python, Node.js und curl. Die API war von Beginn an versioniert (v1 im URL-Pfad). Ergebnis: Die durchschnittliche Integrationszeit betrug 3 Tage statt der branchenüblichen 2 Wochen, und die Support-Tickets lagen 70 % unter denen der vorherigen API-Version.

Beispielantwort

Wir mussten 500 Millionen Datensätze von einem MySQL-Monolithen nach PostgreSQL migrieren, ohne den Betrieb der Applikation zu unterbrechen. Kein Downtime war eine feste Anforderung. Ich entwarf einen schrittweisen Ansatz. Phase 1: PostgreSQL mit dem neuen Schema aufsetzen und Dual-Write implementieren, sodass die Applikation gleichzeitig in beide Datenbanken schreibt. Phase 2: Historische Daten per Batch-Migrationsskript auffüllen, das in Nebenzeiten 100.000 Datensätze pro Stunde verarbeitete und dabei Prüfsummen zur Verifizierung der Datenintegrität einsetzte. Phase 3: Leseverkehr schrittweise per Feature-Flag auf PostgreSQL umleiten, beginnend mit 5 % und über 2 Wochen ansteigend, während wir auf Abweichungen überwachten. Phase 4: Sobald 100 % der Leseanfragen ohne Abweichungswarnungen über PostgreSQL liefen, schalteten wir die MySQL-Schreibvorgänge ab und stellten die alte Datenbank außer Betrieb. Die gesamte Migration dauerte 6 Wochen. Während der Dual-Read-Phase entdeckten wir 3 Dateninkonsistenz-Bugs, die bei einer Big-Bang-Migration zu Produktionsproblemen geführt hätten.

Beispielantwort

Ich führte ein Sicherheits-Audit unseres Authentifizierungssystems durch und stellte mehrere Schwachstellen fest: JWT-Tokens hatten eine Gültigkeitsdauer von 30 Tagen, Refresh-Tokens wurden in localStorage gespeichert (anfällig für XSS-Angriffe), und Rate-Limiting wurde nur auf Login-Endpunkte angewendet. Ich setzte ein umfassendes Sicherheits-Update um: JWT-Ablaufzeit auf 15 Minuten verkürzt mit stiller Erneuerung, Refresh-Tokens in HTTP-only-Secure-Cookies mit SameSite=Strict verschoben, gleitendes Rate-Limiting über alle authentifizierten Endpunkte (100 Anfragen pro Minute pro Nutzer), Request-Signing für sensible Operationen (Überweisungen, Passwortänderungen) sowie Audit-Logging für alle Authentifizierungsereignisse eingeführt. Zusätzlich richtete ich automatisiertes Dependency-Vulnerability-Scanning mit Snyk in unserer CI-Pipeline ein. Nach der Umsetzung bestanden wir einen externen Penetrationstest ohne kritische oder schwerwiegende Befunde. Beim vorherigen Audit waren noch 4 kritische Befunde dokumentiert worden.

Beispielantwort

Das CAP-Theorem besagt, dass ein verteilter Datenspeicher höchstens zwei der drei Eigenschaften gleichzeitig garantieren kann: Konsistenz (jeder Lesezugriff liefert den neuesten Schreibstand), Verfügbarkeit (jede Anfrage erhält eine Antwort) und Partitionstoleranz (das System arbeitet weiter, selbst wenn Knoten keine Verbindung zueinander haben). Da Netzwerkpartitionen in verteilten Systemen unvermeidlich sind, ist die eigentliche Wahl die zwischen Konsistenz und Verfügbarkeit beim Auftreten einer Partition. CP-Systeme wie PostgreSQL mit synchroner Replikation, MongoDB oder HBase verweigern eine Antwort lieber, als veraltete Daten zurückzugeben. Sie eignen sich für Finanzsysteme, bei denen fehlerhafte Daten schlimmer sind als ein Ausfall. AP-Systeme wie Cassandra, DynamoDB oder CouchDB antworten immer, können aber veraltete Daten liefern. Sie sind geeignet für Social-Media-Feeds, Produktkataloge oder Caching-Schichten, bei denen kurzfristige Inkonsistenz akzeptabel ist. In der Praxis entscheide ich anhand der Kosten eines Fehlers: Wenn veraltete Daten finanzielle Schäden oder Sicherheitsprobleme verursachen, wähle ich CP. Wenn kurzzeitige Veraltung für Nutzer unsichtbar ist, wähle ich AP für bessere Verfügbarkeit und niedrigere Latenz.

Beispielantwort

Ich würde vier Algorithmen anhand des Anwendungsfalls bewerten. Fixed Window: Anfragen in festen Zeitintervallen zählen (z. B. 100 pro Minute). Einfach, erlaubt aber Bursts an Fenstergrenzen: Ein Nutzer könnte 100 Anfragen bei 0:59 Uhr und 100 weitere bei 1:00 Uhr stellen. Sliding Window Log: Zeitstempel jeder Anfrage speichern und Anfragen im gleitenden Fenster zählen. Präzise, aber speicherintensiv bei hohem Volumen. Sliding Window Counter: Hybrid aus Fixed Window und Sliding Window. Gute Genauigkeit bei niedrigem Speicherbedarf. Token Bucket: Tokens akkumulieren mit einer festen Rate, jede Anfrage kostet ein Token. Erlaubt kontrollierte Bursts bei gleichzeitiger Einhaltung der Durchschnittsrate. Das ist meine Standardwahl, weil sie intuitiv ist, Burst-Traffic behutsam handhabt und sich einfach implementieren lässt. Für die Umsetzung: Redis mit INCR und EXPIRE für verteiltes Rate-Limiting, mit dem Schlüsselformat user_id:endpoint:window. Ich würde Rate-Limit-Header zurückgeben (X-RateLimit-Remaining, X-RateLimit-Reset), damit Clients sich selbst drosseln können, und HTTP 429 mit einem Retry-After-Header verwenden.

Beispielantwort

Ein Index ist eine Datenstruktur (typischerweise B-Baum oder Hash), die Datenbankabfragen beschleunigt, auf Kosten langsamerer Schreibvorgänge und zusätzlichem Speicherplatz. Vergleichbar mit dem Register eines Buches: Statt jede Seite zu lesen, schlägt man nach und springt direkt zur richtigen Stelle. Indizes verwenden bei: Spalten in WHERE-Klauseln (besonders bei großen Tabellen), JOIN-Spalten, Spalten in ORDER BY sowie Spalten mit hoher Kardinalität (viele eindeutige Werte). Keine Indizes bei: kleinen Tabellen (sequenzieller Scan ist schneller), Spalten mit niedriger Kardinalität (Boolean, Statusfelder mit 3 Werten), häufig aktualisierten Spalten (Index-Pflegeaufwand) oder Tabellen mit hohem Schreibvolumen, bei denen Leseperformance nicht entscheidend ist. Zusammengesetzte Indizes sind wichtig: Ein Index auf (user_id, created_at) hilft bei Abfragen, die beide oder nur user_id filtern, aber nicht bei Abfragen, die nur created_at filtern. Ich nutze EXPLAIN ANALYZE, um zu überprüfen, dass Abfragen tatsächlich die erstellten Indizes verwenden. Der Query-Planner ignoriert Indizes manchmal, wenn er einen sequenziellen Scan für effizienter hält.

Beispielantwort

Klassische ACID-Transaktionen funktionieren über Microservices hinweg nicht, da jeder Service seine eigene Datenbank verwaltet. Die Standardlösung ist das Saga-Muster: eine Folge lokaler Transaktionen, bei der jeder Schritt ein Ereignis veröffentlicht, das den nächsten Schritt auslöst, und jeder Schritt eine kompensierende Transaktion für Rollbacks bereitstellt. Es gibt zwei Ansätze: Choreografie (Services reagieren autonom auf Ereignisse) und Orchestrierung (ein zentraler Koordinator steuert den Ablauf). Für komplexe Abläufe bevorzuge ich Orchestrierung, weil die Logik an einem Ort liegt und sich einfacher debuggen lässt. Beispiel: Die Bestellverarbeitung betrifft den Order-Service (Bestellung anlegen), den Payment-Service (Karte belasten) und den Inventory-Service (Lagerbestand reservieren). Schlägt die Zahlung fehl, ruft der Orchestrator die kompensierende Transaktion des Order-Service auf, um die Bestellung zu stornieren. Schlägt die Lagerreservierung nach erfolgreicher Zahlung fehl, erstattet der Orchestrator die Zahlung und storniert die Bestellung. Wesentliche Aspekte: Idempotenz ist entscheidend (jeder Schritt muss doppelte Aufrufe vertragen), kompensierende Transaktionen müssen zuverlässig sein, und man braucht Transparenz über den Saga-Zustand für das Debugging fehlgeschlagener Abläufe.

Beispielantwort

Sofortmaßnahmen (erste 15 Minuten): Aggressives Caching auf CDN/Reverse-Proxy-Ebene für leseintensive Endpunkte aktivieren. Auto-Scaling für Applikationsserver einschalten, falls es noch nicht läuft. Prüfen, ob die Datenbank der Engpass ist: Falls ja, Read-Replicas für GET-Anfragen aktivieren und Connection-Pooling hinzufügen (PgBouncer für PostgreSQL). Kurzfristig (nächste Stunde): Request-Throttling für unkritische Endpunkte einführen, um kritische Pfade zu schützen. Schreibvorgänge, die asynchron verarbeitet werden können (Nutzer-Analytics-Events, E-Mail-Benachrichtigungen), in eine Warteschlange auslagern. Circuit-Breaker für externe Serviceaufrufe in Betracht ziehen, um Kaskadenausfälle zu verhindern. Bei erwartetem Traffic (viraler Moment, Produktstart): Horizontal skalieren, Caching-Schichten hinzufügen und die häufigsten Datenbankabfragen optimieren. Bei unerwartetem Traffic (potenzieller DDoS-Angriff): Traffic-Muster prüfen, IP-basiertes Rate-Limiting aktivieren und WAF-Regeln erwägen. Nach dem Spike: Kapazitätsplanung überprüfen und Skalierungsschwellen festlegen, die das nächste Mal automatisch greifen.

Beispielantwort

Auf einer Tabelle mit einer Milliarde Datensätzen in der Produktion direkt ALTER TABLE auszuführen kommt nicht in Frage: Das würde die Tabelle für Stunden sperren. Ich würde ein Online-Schema-Migrationstool verwenden, etwa pt-online-schema-change (MySQL) oder pg-osc (PostgreSQL). Diese Tools erstellen eine Schattenkopie der Tabelle, wenden die Änderung an, synchronisieren Daten über Trigger und tauschen Tabellen mit minimaler Sperrzeit. Für das Hinzufügen einer Spalte: Zunächst als nullable hinzufügen (schnell, kein Table-Rewrite), dann die Daten in Batches in Nebenzeiten auffüllen (10.000 Datensätze pro Batch mit 100 ms Pause zwischen den Batches) und danach bei Bedarf die NOT NULL-Einschränkung setzen. Für die Änderung eines Spaltentyps: Eine neue Spalte mit dem Zieltyp anlegen, während der Migration in beide Spalten schreiben, die neue Spalte auffüllen, die Applikation auf die neue Spalte umstellen und dann die alte Spalte löschen. Die Grundprinzipien: Jeder Schritt muss rückgängig zu machen sein, die Migration muss im Hintergrund ohne Sperren laufen, und die Applikation muss in jedem Zwischenzustand korrekt funktionieren.

Beispielantwort

Als erstes würde ich ein Circuit-Breaker-Muster implementieren. Nach N aufeinanderfolgenden Fehlern (z. B. 5) öffnet sich der Schalter: Die API wird nicht mehr aufgerufen, und stattdessen wird eine Fallback-Antwort zurückgegeben (gecachte Daten, Standardwerte oder eine verständliche Fehlermeldung), solange die Abklingzeit läuft. Nach der Abklingzeit lässt man eine einzelne Testanfrage durch. Gelingt sie, schließt sich der Schalter, und der normale Betrieb wird wieder aufgenommen. Als zweites würde ich Retry-Logik mit exponentiellem Backoff für vorübergehende Fehler hinzufügen: Wiederholung nach 1 Sekunde, dann 2 Sekunden, dann 4 Sekunden, mit Jitter, um ein Thundering-Herd-Problem zu vermeiden. Als drittes würde ich eine Anfragewarteschlange implementieren, damit Operationen, die von dieser API abhängen, bei einem Fehler später erneut versucht werden können. Als viertes würde ich das Team benachrichtigen und die Statusseite des Drittanbieters prüfen. Bei anhaltenden Problemen kämen aggressiveres Caching, ein Fallback auf einen alternativen Anbieter oder das Stapeln von Anfragen für die Batch-Verarbeitung in stabilen Phasen in Betracht. Langfristig gilt: Für jede kritische Drittanbieter-Abhängigkeit sollte man ein Service-Level-Agreement vorhalten und eine dokumentierte Fallback-Strategie bereit haben, bevor der erste Ausfall eintritt.

Beispielantwort

Ich würde das System ereignisgesteuert mit drei Schichten aufbauen. Erste Schicht, die Anfrageschicht: Services veröffentlichen Benachrichtigungsereignisse in eine Message-Queue (RabbitMQ oder SQS) mit einer kanalunabhängigen Payload, bestehend aus Empfänger, Benachrichtigungstyp, Template-Name und Template-Variablen. Das entkoppelt den Sender von der Auslieferungslogik. Zweite Schicht, die Orchestrierungsschicht: Ein Benachrichtigungsservice konsumiert Ereignisse, liest Nutzereinstellungen (welche Kanäle aktiviert sind), löst Templates auf und veröffentlicht kanalspezifische Nachrichten in kanalspezifische Queues (E-Mail-Queue, Push-Queue, SMS-Queue). Dritte Schicht, die Auslieferungsschicht: Kanalspezifische Worker konsumieren aus ihrer Queue und rufen den jeweiligen Anbieter auf (SendGrid für E-Mail, FCM/APNs für Push, Twilio für SMS). Jeder Worker handhabt Wiederholungsversuche, Rate-Limiting und anbieterspezifische Logik eigenständig. Wichtige Designentscheidungen: Idempotenz-Schlüssel zur Vermeidung doppelter Zustellungen, ein Benachrichtigungsprotokoll für Audit und Debugging, Nutzerpräferenz-Speicherung für Opt-out und Kanalauswahl sowie Template-Versionierung, damit Templates ohne Redeployment aktualisiert werden können. Außerdem würde ich eine Dead-Letter-Queue für dauerhaft fehlgeschlagene Benachrichtigungen mit entsprechenden Warnmeldungen einrichten.