Middle Node.js-Backend — Node.js-Interviewfragen

Warum ist eine CPU-lastige Operation in Node gefährlich, und was macht man dagegen?

Weil sie den einen Thread belegt, der jeden Request bedient — eine zweisekündige Berechnung lässt jeden gleichzeitigen Nutzer zwei Sekunden warten. Die Optionen sind, sie in einen Worker Thread, einen separaten Prozess oder eine Queue auszulagern oder den Algorithmus zu ersetzen. Die Falle ist, dass es bei geringem Traffic in der Entwicklung unauffällig aussieht und unter Last als Latenz-Klippe erscheint.

Wofür sind Streams da, und wann tut es weh, sie nicht zu nutzen?

Sie erlauben es, Daten in Chunks zu verarbeiten, statt sie komplett im Speicher zu halten. Ein Ein-Gigabyte-Upload per readFile einzulesen allokiert ein Gigabyte pro gleichzeitigem Request — so stirbt ein Service schon bei drei parallelen Uploads. Piping hält den Speicherverbrauch unabhängig von der Dateigröße konstant. Backpressure ist der Teil, den man gern überspringt: Ist das Ziel langsamer als die Quelle, puffert ein ungepipter Stream so lange, bis dem Prozess der Speicher ausgeht.

Du hast einen Memory Leak in Produktion. Wie findest du ihn?

Erst bestätigen — ein steigender Heap, der nach der Garbage Collection nie wieder zurückgeht, statt des normalen Sägezahnmusters. Dann unter Last zwei Heap-Snapshots im Abstand von Minuten nehmen und die retained objects vergleichen; der Diff nennt den Übeltäter meist direkt. Die üblichen Ursachen sind ein wachsender Cache ohne Eviction, Listener, die pro Request hinzugefügt und nie entfernt werden, und Closures, die ein großes Objekt am Leben halten.

Was bringt Clustering, und was nicht?

Es startet einen Prozess pro Core, sodass du die ganze Maschine nutzt statt eines einzelnen Threads, während das Betriebssystem die Verbindungen verteilt. Was es nicht bringt, ist gemeinsamer Zustand — alles, was im Speicher lag, existiert jetzt pro Worker, sodass In-Process-Caches auseinanderlaufen und Sessions kaputtgehen, sofern sie nicht nach Redis wandern. Und einen langsamen Handler behebt es auch nicht — es vervielfacht nur die Anzahl der Stellen, an denen es langsam sein kann.

Wie vermeidest du ein N+1-Problem mit einem ORM in Node?

Genauso wie überall: im Log eine Query pro Element bemerken und dann die zugehörigen Zeilen in einer einzigen Query laden. Prisma hat include, Sequelize hat Eager Loading, und ein rohes join funktioniert immer. Die Node-spezifische Falle ist await innerhalb einer for-Schleife, das Aufrufe serialisiert, die eigentlich zusammen laufen könnten — Promise.all behebt die Latenz, aber nicht die Anzahl der Queries.

Was prüfst du, wenn ein Node-Service unter Last langsam wird?

Ob der Event Loop blockiert ist — eine Lag-Metrik beantwortet das direkt, Raten nicht. Ist die Schleife in Ordnung, steckt die Zeit in einem nachgelagerten Aufruf — Datenbank, ein vorgelagertes API —, und ein erschöpfter Connection Pool ist eine häufige Ursache. Logs der durchschnittlichen Latenz verbergen das; Perzentile nicht, denn genau im p99 lebt die Pool-Erschöpfung.

Wie testest du Code, der ein externes API aufruft?

Auf der HTTP-Ebene abfangen, etwa mit nock, statt den eigenen Client zu mocken, damit der Test den echten Requestaufbau und das echte Parsing durchläuft. Eine echte Antwort als Fixture aufzeichnen und dagegen prüfen. Den eigenen Wrapper zu mocken testet nur, ob dein Mock zu deinem Mock passt — deshalb bleiben solche Suiten grün, während die Integration bricht.