Was wird im Vorstellungsgespräch als Backend-Entwickler am häufigsten gefragt?

API-Design, Datenbanken, Indizes und Transaktionen, Caching, Queues, Ausfälle zwischen Services, Sicherheit, Skalierung und Monitoring, und für Senior-Rollen Systemdesign und Service-Grenzen.

Gibt es eine Programmierrunde?

Meistens: eine Programmieraufgabe in deiner Sprache, oft mit Datenstrukturen, und manchmal eine kleine API, die du bauen sollst. Erklär dabei dein Vorgehen und deine Tests.

Muss ich Microservices kennen?

Du solltest wissen, was sie lösen und was sie kosten. Viele Teams betreiben einen gut strukturierten Monolithen, und Interviewer mögen Kandidaten, die sagen können, wann man nicht aufteilt.

Wie tief sollte mein Datenbankwissen sein?

Tief genug, um einen Ausführungsplan zu lesen, einen Index zu wählen, eine Transaktion zu erklären und mit zwei gleichzeitigen Schreibzugriffen umzugehen.

Wie bereite ich mich in einer Woche vor?

Sag die zwei ausgearbeiteten Antworten laut, übe ein Systemdesign laut mit einem Timer, lies den Ausführungsplan einer eigenen langsamen Abfrage und bereite je eine Geschichte vor: über einen Ausfall, eine Beschleunigung und ein Design, das du heute anders machen würdest.

Interviewfragen für Backend-Entwickler, mit ausgearbeiteten Antworten

Sechzehn Fragen, die in Vorstellungsgesprächen für Backend-Entwickler immer wieder kommen, vom ersten Backend-Job bis zum Staff Engineer, Principal Engineer und Softwarearchitekten. Zu jeder: worauf der Interviewer achtet, eine kurze Antwort, die ausführliche Antwort in einfachen Worten, eine schwache Antwort, die du vermeiden solltest, und eine typische Nachfrage.

Das cvscored-TeamVeröffentlicht 05.11.2026 · Aktualisiert 05.11.2026

Inhalt

So nutzt du diese Fragen
Was ein Backend-Entwickler können muss
APIs
Datenbanken und Transaktionen
Caching, Queues und Ausfälle
Sicherheit, Skalierung und Betrieb in Produktion
Fragen für Staff, Principal und Architekten
Dein Lebenslauf für diese Fragen
Das Wichtigste
Häufige Fragen
Mehr zu diesem Beruf

So nutzt du diese Fragen

Lies die kurze Antwort und sag sie laut; das ist deine erste halbe Minute. Nimm dann zwei oder drei Punkte aus der ausführlichen Antwort und ergänze einen Service, an dem du gearbeitet hast: seine Last, was ausgefallen ist, was du gemessen und was du geändert hast. Backend-Interviewer hören auf Fehlerfälle; nenn sie, bevor sie danach fragen.

Was ein Backend-Entwickler können muss

Eine Sprache in der Tiefe: Java mit Spring, Python, C#, Go oder Node.js: ihr Speicher, ihr Modell für Threads oder Async und ihre Testwerkzeuge.
Daten: SQL, Indizes und Transaktionen in einer Datenbank wie PostgreSQL; wann ein Cache wie Redis oder ein Document Store hilft.
APIs: REST-APIs, die klar, versioniert und sicher wiederholbar sind.
Zwischen Services: Queues wie RabbitMQ, Event-Logs wie Kafka, Timeouts und Wiederholungen.
Betrieb: Docker, CI/CD, Logs, Metriken mit Werkzeugen wie Prometheus und Rufbereitschaft.
Sicherheit: Anmeldung, Zugriffsregeln, Secrets und personenbezogene Daten nach der DSGVO (EU) und ähnlichen Gesetzen.

APIs

Eine mobile App wiederholt eine Anfrage, wenn das Netz abbricht. Wie stellst du sicher, dass die Zahlung nur einmal passiert?

Worauf sie achten: dass du mit Wiederholungen rechnest und für sie entwirfst, der Kern einer sicheren API.

Kurze Antwort: „Ich mache die Anfrage idempotent: Zweimal ausgeführt, hat sie dieselbe Wirkung wie einmal. Die App schickt mit jeder Zahlung einen eindeutigen Schlüssel; der Server speichert den Schlüssel mit dem Ergebnis, und eine Wiederholung mit demselben Schlüssel bekommt das gespeicherte Ergebnis statt einer zweiten Abbuchung.“

Die ausführliche Antwort in fünf Schritten:

Ein Schlüssel pro Aktion. Der Client erzeugt einen Idempotency Key, einen eindeutigen Wert, wenn der Nutzer auf Bezahlen drückt, und schickt ihn bei jeder Wiederholung genau dieser Aktion mit.
Zuerst speichern. Der Server speichert den Schlüssel in derselben Datenbanktransaktion wie den Zahlungsdatensatz, mit einem Unique Constraint, sodass nicht zwei Anfragen mit demselben Schlüssel durchkommen.
Die Wiederholung beantworten. Gibt es den Schlüssel schon und ist die Arbeit erledigt, gib das gespeicherte Ergebnis zurück. Läuft sie noch, sag das und lass den Client später noch einmal fragen.
Den Aufruf beim Anbieter schützen. Gib denselben Schlüssel an den Zahlungsanbieter weiter, was die meisten Anbieter akzeptieren, damit auch eine Wiederholung von deiner Seite nicht doppelt abbucht.
Ablaufen lassen. Bewahre Schlüssel lange genug auf, um Wiederholungen abzudecken, zum Beispiel einen Tag, und räume sie dann auf.

Schwache Antwort: „Ich prüfe, ob der Nutzer in der letzten Minute bezahlt hat.“ Zwei Anfragen, die gleichzeitig ankommen, sehen beide keine Zahlung und buchen beide ab.

Nachfrage: „Welche HTTP-Methoden sind schon idempotent?“ GET, PUT und DELETE sollen es sein; POST nicht, deshalb braucht das Anlegen einer Zahlung den Schlüssel.

Wie änderst du eine API, ohne die Apps kaputtzumachen, die sie schon nutzen?

Worauf sie achten: Respekt vor Clients, die du nicht kontrollierst, etwa alten App-Versionen.

Kurze Antwort: „In derselben Version ergänze ich nur, ich ändere oder entferne nie: neue optionale Felder und neue Endpunkte sind sicher. Eine Breaking Change bekommt eine neue Version, beide laufen nebeneinander, und die alte wird abgeschaltet, wenn ihre Nutzer umgezogen sind, mit einem früh angekündigten Termin.“

Die ausführliche Antwort: Mobile Apps bleiben jahrelang installiert; eine API kann also nicht davon ausgehen, dass jeder Client aktualisiert. Die Version kann im Pfad oder in einem Header stehen; die Wahl ist weniger wichtig als Einheitlichkeit. Veröffentliche die Beschreibung der API, zum Beispiel als OpenAPI-Datei, und teste, dass Änderungen alte Anfragen weiter funktionieren lassen (Contract-Tests). Logge, welche Clients noch die alte Version aufrufen, damit du weißt, wann du sie gefahrlos abschalten kannst.

Schwache Antwort: „Wir sagen dem Frontend-Team, dass es aktualisieren soll.“ Nachfrage: „Ein Feld muss umbenannt werden.“ Den neuen Namen ergänzen, den alten weiter mitschicken und ihn erst in der nächsten Version entfernen.

Datenbanken und Transaktionen

Wie macht ein Index eine Abfrage schnell, und wann macht ein neuer Index alles schlimmer?

Worauf sie achten: dass du die Datenbank verstehst, statt aus Gewohnheit Indizes anzulegen.

Kurze Antwort: „Ein Index ist eine sortierte Kopie einiger Spalten, die auf die Zeilen zeigt, sodass die Datenbank Zeilen findet, ohne die ganze Tabelle zu lesen. Jeder Index macht Schreibzugriffe langsamer und braucht Platz; ich lege also einen für eine echte langsame Abfrage an, prüfe den Ausführungsplan und entferne die, die niemand nutzt.“

Die ausführliche Antwort: Der Ausführungsplan, den die Datenbank zeigt, wenn man sie eine Abfrage erklären lässt, sagt, ob sie die ganze Tabelle liest oder einen Index nutzt. Ein zusammengesetzter Index auf zwei Spalten hilft Abfragen, die nach der ersten Spalte filtern; die Reihenfolge zählt. Ein Index auf einer Spalte mit wenigen Werten, etwa Ja oder Nein, hilft selten. Eine Tabelle mit vielen Schreibzugriffen, etwa ein Event-Log, bezahlt für jeden Index bei jedem Insert. Einen Index auf einer großen, laufenden Tabelle anzulegen, kann sie sperren; die meisten Datenbanken bieten deshalb einen Weg, ihn zu bauen, ohne Schreibzugriffe zu blockieren.

Schwache Antwort: „Einen Index auf jede Spalte legen.“ Nachfrage: „Der Index existiert, aber der Plan nutzt ihn nicht. Warum?“ Die Abfrage packt die Spalte in eine Funktion, die Typen passen nicht, oder die Datenbank hält das Lesen der Tabelle für günstiger, weil der Filter auf die meisten Zeilen passt.

Zwei Nutzer buchen im selben Moment den letzten Platz. Wie sorgt dein Service dafür, dass nur einer ihn bekommt?

Worauf sie achten: Transaktionen, Isolation und Sperren, in einfachen Worten erklärt.

Kurze Antwort: „Ich lasse die Datenbank entscheiden. Entweder ist das Update an eine Bedingung geknüpft, etwa ‚nimm den Platz nur, wenn er noch frei ist‘, und ich prüfe, dass genau eine Zeile geändert wurde; oder ich sperre die Zeile in einer Transaktion. Ein Unique Constraint auf Platz und Veranstaltung ist das letzte Sicherheitsnetz.“

Die ausführliche Antwort: Eine Transaktion fasst Änderungen so zusammen, dass alle passieren oder keine. Die Isolation entscheidet, was eine Transaktion von einer anderen sieht, die zur selben Zeit läuft; je stärker die Isolation, desto weniger Überraschungen und desto mehr Warten. Die meisten Datenbanken nutzen standardmäßig eine Stufe, auf der zwei Transaktionen beide ‚frei‘ lesen und beide schreiben können. Optionen: optimistisches Sperren (jede Zeile hat eine Versionsnummer, und ein Schreibzugriff schlägt fehl, wenn sich die Version geändert hat), pessimistisches Sperren (die Zeile sperren, während du arbeitest) oder eine strengere Isolationsstufe für genau diese Transaktion. Halte Transaktionen kurz und warte darin nie auf einen langsamen Aufruf nach außen.

Schwache Antwort: „Ich prüfe im Code, ob der Platz frei ist, und speichere dann.“ Nachfrage: „Deine Transaktion hängt jetzt in einem Deadlock. Was ist passiert?“ Zwei Transaktionen haben Zeilen in umgekehrter Reihenfolge gesperrt; sperre in einer festen Reihenfolge und wiederhole bei einem Deadlock.

Wie entscheidest du dich für einen neuen Service zwischen einer relationalen Datenbank und einer Dokumentendatenbank?

Worauf sie achten: dass du nach den Daten und den Fragen an sie wählst, nicht nach Mode.

Kurze Antwort: „Ich fange relational an, mit PostgreSQL, außer ich habe einen Grund dagegen. Zusammenhängende Daten, Transaktionen und Berichte sind ihre Stärke. Eine Dokumentendatenbank wie MongoDB passt für Daten, die als ein Stück gelesen und geschrieben werden und deren Form stark schwankt.“

Die ausführliche Antwort: Frag, wie die Daten aussehen, wie sie gelesen werden und was konsistent bleiben muss. Bestellungen, Kunden und Zahlungen hängen zusammen und brauchen Transaktionen: relational. Ein Produktkatalog mit sehr unterschiedlichen Attributen pro Produkt oder Event-Daten, die als Ganzes gelesen werden, können zu MongoDB passen; viele relationale Datenbanken speichern heute auch flexible JSON-Felder. Denk an das Team: was es sichern, überwachen und nachts reparieren kann. Die Datenbank später zu wechseln, ist teuer; die Standardwahl sollte also die langweilige sein.

Schwache Antwort: „NoSQL skaliert besser.“ Nachfrage: „Berichte brauchen in deinem Document Store Joins über Bestellungen und Kunden.“ Die Daten für Berichte in ein Data Warehouse kopieren oder die Wahl überdenken.

Caching, Queues und Ausfälle

Wo würdest du einen Cache einbauen, und wie verhinderst du, dass er alte Daten liefert?

Worauf sie achten: dass du die Kosten des Cachings kennst: veraltete Daten und schwierigere Fehler.

Kurze Antwort: „Ich cache Daten, die viel öfter gelesen als geändert werden und bei denen ein paar Sekunden alte Daten in Ordnung sind, etwa eine Produktseite. Jeder Eintrag hat eine Ablaufzeit, und eine Änderung an den Daten löscht ihren Eintrag. Ich messe die Trefferquote, um zu sehen, ob der Cache hilft.“

Die ausführliche Antwort: Caches sitzen an mehreren Stellen: im Browser, in einem CDN (Server in der Nähe des Nutzers, die Kopien von Seiten halten), im Speicher des Service oder in einem gemeinsamen Speicher wie Redis. Das übliche Muster: aus dem Cache lesen und bei einem Fehltreffer die Datenbank lesen und den Cache füllen. Der schwierige Teil ist die Invalidierung, das Entfernen von Einträgen, wenn sich die Daten ändern. Daten, die exakt sein müssen, etwa ein Kontostand oder der Lagerbestand im Checkout, werden frisch gelesen. Achte auf eine Stampede: Ein beliebter Eintrag läuft ab, und Tausende Anfragen treffen gleichzeitig die Datenbank; erneuere ihn früh oder lass nur eine Anfrage ihn neu aufbauen.

Schwache Antwort: „Alles für eine Stunde cachen.“ Nachfrage: „Nutzer sehen nach einer Änderung noch ihren alten Namen.“ Ihren Eintrag löschen, wenn sich der Name ändert, und das eigene Profil frisch lesen.

Wann würdest du Arbeit in eine Queue legen, statt sie in der Anfrage zu erledigen?

Worauf sie achten: dass du weißt, was eine Queue bringt und was sie kostet.

Kurze Antwort: „Wenn der Nutzer das Ergebnis nicht braucht, um weiterzumachen, oder die Arbeit langsam ist oder fehlschlagen kann: E-Mails senden, ein PDF erzeugen, einen langsamen Partner aufrufen. Die Anfrage speichert den Job und antwortet sofort; ein Worker erledigt den Job, wiederholt ihn bei einem Fehler, und ein gescheiterter Job landet dort, wo wir ihn sehen.“

Die ausführliche Antwort: Eine Queue wie RabbitMQ gibt jeden Job an einen Worker. Ein Event-Log wie Kafka hält Events in Reihenfolge für viele Leser, die sie später noch einmal abspielen können. So oder so kann ein Job zweimal ankommen; Worker müssen also idempotent sein. Jobs, die immer wieder fehlschlagen, kommen in eine Dead-Letter-Queue, um angeschaut zu werden, statt ewig wiederholt zu werden. Achte auf die Länge der Queue: Wächst sie, sind die Worker zu langsam oder kaputt. Das Speichern in der Datenbank und das Veröffentlichen des Jobs dürfen nicht auseinanderlaufen; das Outbox-Muster schreibt den Job in derselben Transaktion in eine Tabelle, und ein eigener Prozess veröffentlicht ihn.

Schwache Antwort: „Queues machen alles schneller.“ Sie machen die Anfrage schneller; die Arbeit selbst dauert genauso lange. Nachfrage: „Der Nutzer will wissen, wann das PDF fertig ist.“ Gib dem Job eine ID, die er abfragen kann, oder benachrichtige ihn, wenn er fertig ist.

Ein Service, den du aufrufst, wird langsam, und bald fällt auch deiner aus. Was tust du?

Worauf sie achten: Ausfälle zwischen Services: Timeouts, Wiederholungen und Circuit Breaker.

Kurze Antwort: „Jeder Aufruf nach außen bekommt einen Timeout, damit langsam nicht zu festgefahren wird. Wiederholungen gibt es wenige, mit wachsenden Wartezeiten und etwas Zufall, und nur für sichere Anfragen. Ein Circuit Breaker hört auf, einen Service aufzurufen, der immer wieder ausfällt, und ich zeige einen sinnvollen Ersatz statt einer Fehlerseite.“

Die ausführliche Antwort: Ohne Timeout hält jeder langsame Aufruf einen Thread oder eine Verbindung fest; gehen sie aus, antwortet dein Service niemandem mehr, auch nicht Anfragen, die den langsamen Service gar nicht brauchen. Wiederholungen ohne Grenze machen den Ausfall schlimmer, weil jeder Client seine Last verdoppelt. Ein Circuit Breaker zählt Fehler und schlägt ab einer Grenze eine Weile sofort fehl, dann lässt er ein paar Anfragen zum Test durch. Getrennte Pools für jede Abhängigkeit (Bulkheads) verhindern, dass eine alles aufbraucht. Den Ersatz entscheidest du mit dem Produktmanager: ein alter Preis aus dem Cache, eine Meldung oder eine Queue für später.

Schwache Antwort: „Ich wiederhole, bis es klappt.“ Nachfrage: „Welchen Timeout würdest du wählen?“ Einen, der sich an der normalen Antwortzeit dieses Service orientiert, etwas über seinen langsamsten normalen Antworten, und der in der Zeit bleibt, die dein eigener Aufrufer erlaubt.

Sicherheit, Skalierung und Betrieb in Produktion

Wie melden sich Nutzer bei deiner API an, und wie weisen Services sich gegenseitig aus?

Worauf sie achten: Authentifizierung (wer du bist) und Autorisierung (was du darfst), sauber getrennt.

Kurze Antwort: „Nutzer melden sich über einen Identity Provider mit OAuth und OpenID Connect an, und die API bekommt ein signiertes Token, das sie ohne Datenbankaufruf prüfen kann. Jede Anfrage prüft dann die Autorisierung: Darf dieser Nutzer diese Bestellung sehen? Services nutzen eigene Zugangsdaten oder Tokens, mit nur den Rechten, die sie brauchen.“

Die ausführliche Antwort: Bau die Passwortspeicherung nicht selbst, wenn ein erprobter Anbieter das kann. Tokens sind kurzlebig, und ein Refresh Token holt ein neues. Der häufigste echte Fehler ist Broken Access Control: Die API prüft, dass der Nutzer angemeldet ist, aber nicht, dass Bestellung 1234 ihm gehört. Prüf die Zugehörigkeit bei jeder Anfrage, an einer gemeinsamen Stelle. Bewahre Secrets in einem Secret Store auf, nie im Code. Personenbezogene Daten werden nach der DSGVO (EU) und ähnlichen Gesetzen geschützt und nicht länger als nötig gespeichert; Sicherheits-Reviews suchen genau nach diesen Punkten.

Schwache Antwort: „Wir nutzen HTTPS, also ist es sicher.“ HTTPS schützt die Verbindung, nicht die Regeln. Nachfrage: „Wie meldest du einen Nutzer ab, dessen Token noch zehn Minuten gültig ist?“ Tokens kurz halten und für sensible Aktionen eine Liste widerrufener Sessions führen.

Dein Service muss in zwei Monaten zehnmal so viel Traffic wie heute verkraften. Wie bereitest du dich vor?

Worauf sie achten: Skalierung auf Basis von Messungen, und dass du weißt, wo Systeme zuerst brechen.

Kurze Antwort: „Ich messe mit einem Lasttest, wo die Grenze heute liegt, denn meist ist es die Datenbank, nicht der Service. Ich mache den Service zustandslos, damit ich mehr Kopien betreiben kann, nehme mit Caching und Lesekopien Last von der Datenbank, verlege langsame Arbeit in Queues und teste auf dem neuen Niveau noch einmal.“

Die ausführliche Antwort in fünf Schritten:

Die Form kennen. Zehnmal so viel im Durchschnitt oder zehnmal so viel an einem Abend? Welche Endpunkte? Die Spitzen bestimmen das Design.
Die Grenze finden. Lass einen Lasttest gegen eine Kopie der Produktion laufen und beobachte, was zuerst voll ist: Datenbankverbindungen, CPU, Speicher, das Rate Limit eines Partners.
In die Breite skalieren. Halte keinen Nutzerzustand im Speicher des Service, damit ein Load Balancer Anfragen auf mehr Kopien verteilen kann, und richte automatische Skalierung auf Kubernetes oder in der Cloud ein.
Die Datenbank schützen. Ergänze die fehlenden Indizes, cache, was oft gelesen wird, schick Lesezugriffe an Replikate und nutze Connection Pools. Erst dann über das Aufteilen der Daten nachdenken.
Für Überlast planen. Rate Limits, eine Queue für Arbeit, die warten kann, und eine klare Meldung, wenn der Service voll ist, sind besser als ein langsamer Zusammenbruch.

Schwache Antwort: „Wir steigen auf Microservices um.“ Das ändert die Struktur; die Grenze der Datenbank bleibt.

Nachfrage: „Der Lasttest besteht, aber am Launch-Tag fällt die Produktion aus.“ Der Test entsprach nicht dem echten Verhalten, etwa dass alle auf einen beliebten Artikel zugreifen; teste mit echten Traffic-Mustern und halte einen schnellen Weg bereit, Funktionen abzuschalten.

Viele Anfragen kommen gleichzeitig an. Wie geht deine Sprache damit um, und was geht zuerst aus?

Worauf sie achten: dass du das Nebenläufigkeitsmodell der Sprache kennst, in der du schreibst, nicht nur ihre Syntax.

Kurze Antwort: „In Java mit Spring bekommt klassisch jede Anfrage einen Thread aus einem Pool; Node.js und die Async-Frameworks von Python lassen viele Anfragen auf einem Thread laufen und wechseln, während sie warten. So oder so gehen meist nicht die Threads zuerst aus, sondern der Connection Pool der Datenbank; ich lege also die Größe dieses Pools fest und halte Arbeit kurz, die eine Verbindung belegt.“

Die ausführliche Antwort: Ein Thread pro Anfrage ist leicht zu durchschauen, braucht aber Speicher pro Thread; die Virtual Threads von Java machen heute viele günstige Threads möglich. Eine Event Loop wie in Node.js bewältigt Tausende wartende Anfragen auf einem Thread, aber eine langsame Berechnung blockiert alle, deshalb kommt schwere Arbeit in einen Worker. Go lässt viele leichte Goroutinen über wenige Threads laufen. In jedem Modell brauchen geteilte Daten Sorgfalt: Zwei Anfragen, die dasselbe Objekt im Speicher gleichzeitig ändern, liefern falsche Ergebnisse. Beobachte die Pool-Größen in den Metriken: belegte Threads, genutzte Verbindungen, wartende Anfragen.

Schwache Antwort: „Async ist immer schneller.“ Es hilft, während Anfragen warten; für Arbeit, die den Prozessor beschäftigt, bringt es nichts. Nachfrage: „Anfragen laufen in Timeouts, aber die CPU ist niedrig.“ Sie warten auf etwas, meist auf Verbindungen aus einem Pool, der zu klein ist oder zu lange belegt wird.

Was loggst, misst und alarmierst du bei einem Backend-Service?

Worauf sie achten: Observability: ob du in der Produktion schnell erkennst, was falsch ist.

Kurze Antwort: „Für jeden Endpunkt messe ich Anfragerate, Fehlerrate und wie lange Anfragen dauern, auch die langsamen. Logs sind strukturiert und tragen eine Request-ID durch jeden Service. Alarme gehen bei dem los, was Nutzer spüren, etwa Fehler oder Langsamkeit, nicht bei jedem hohen CPU-Wert.“

Die ausführliche Antwort: Metriken, zum Beispiel in Prometheus, zeigen Trends; Logs zeigen einzelne Ereignisse; Traces verfolgen eine Anfrage durch mehrere Services. Miss auch die langsamsten Anfragen (das 95. oder 99. Perzentil), denn Durchschnitte verstecken sie. Vereinbare mit dem Product Owner ein Service Level Objective, etwa wie viele Anfragen in einem Monat fehlschlagen dürfen, und alarmiere, wenn dieses Budget zu schnell aufgebraucht wird. Logge nie Passwörter, Tokens oder vollständige Kartennummern. Jeder Alarm sollte sagen, was zu tun ist; ein Alarm, auf den niemand reagiert, ist Rauschen.

Schwache Antwort: „Wir loggen alles und suchen bei Bedarf.“ Nachfrage: „Ein Nutzer sagt, die App war gegen 3 Uhr nachmittags langsam. Wie findest du heraus, warum?“ Seine Anfragen über Nutzer- oder Request-ID finden, dem Trace folgen und mit den Metriken zu dieser Zeit vergleichen.

Fragen für Staff, Principal und Architekten

Eine Bestellung berührt den Bestell-, den Zahlungs- und den Lager-Service. Wie hältst du die Daten konsistent, ohne eine gemeinsame Transaktion?

Worauf sie achten: bei Senior- und Staff-Rollen Konsistenz über Services hinweg und ehrliche Abwägungen.

Kurze Antwort: „Ich akzeptiere, dass sich die Services etwas später einig sind, nicht im selben Augenblick, und entwerfe dafür. Jeder Service ändert seine eigenen Daten und veröffentlicht ein Event. Eine Saga, eine Kette von Schritten mit je einem Rückgängig-Schritt, steuert die Bestellung; schlägt die Zahlung fehl, wird der Lagerbestand wieder freigegeben.“

Die ausführliche Antwort: Eine Transaktion über Services hinweg, etwa ein Two-Phase Commit, ist langsam und scheitert schlecht; die meisten Systeme nutzen deshalb Eventual Consistency: Die Daten werden nach kurzer Zeit konsistent. Eine Saga kann choreografiert sein (jeder Service reagiert auf Events) oder orchestriert (ein Service steuert die Schritte); Orchestrierung ist bei vielen Schritten leichter nachzuvollziehen. Jeder Schritt muss idempotent sein, und sein Rückgängig-Schritt muss existieren. Das Outbox-Muster stellt sicher, dass ein Event genau dann veröffentlicht wird, wenn sich die Daten geändert haben. Zeig den Nutzern die Zwischenzustände ehrlich, etwa ‚Zahlung ausstehend‘.

Schwache Antwort: „Eine Datenbank für alle Services nehmen.“ Nachfrage: „Der Rückgängig-Schritt schlägt selbst fehl.“ Ihn wiederholen, einen Menschen alarmieren, wenn er weiter fehlschlägt, und einen Datensatz führen, damit nichts verloren geht.

Entwirf das Backend für Benachrichtigungen, die Millionen Nutzer per E-Mail und Push-Nachricht erreichen.

Worauf sie achten: bei Senior- und Staff-Rollen ein Systemdesign von den Anforderungen bis zu den Fehlerfällen.

Kurze Antwort: „Andere Services schicken eine Benachrichtigungsanfrage an eine einzige API. Sie prüft die Einstellungen des Nutzers, schreibt einen Job in eine Queue, und Worker pro Kanal senden über die E-Mail- und Push-Anbieter, mit Wiederholungen und Rate Limits. Jede Nachricht wird protokolliert, damit wir sehen, was gesendet wurde, und nie etwas doppelt senden.“

Die ausführliche Antwort: Fang mit den Anforderungen an: wie viele Nachrichten in der Spitze, wie schnell sie ankommen müssen, welche dringend sind (ein Login-Code) und welche warten können (ein Newsletter). Getrennte Queues verhindern, dass der Newsletter den Login-Code aufhält. Anbieter begrenzen, wie schnell du senden darfst, also takten sich die Worker selbst. Speichere den Status jeder Nachricht für Supportfragen und für die Regeln zu Abmeldung und Einwilligung. Ein eindeutiger Schlüssel pro Nachricht verhindert Duplikate, wenn ein Worker wiederholt. Vorlagen und Sprachen liegen beim Benachrichtigungs-Service, nicht bei jedem Aufrufer.

Schwache Antwort: „Jeder Service schickt seine eigenen E-Mails.“ Nachfrage: „Der E-Mail-Anbieter ist eine Stunde lang nicht erreichbar.“ Die Queue hält die Nachrichten; dringende weichen auf einen zweiten Anbieter aus.

Du sollst einen großen Monolithen in Services aufteilen. Wie legst du die Grenzen der Services fest?

Worauf sie achten: bei Rollen als Staff Engineer, Principal Engineer und Softwarearchitekt ein Design, das dem Geschäft und den Teams folgt.

Kurze Antwort: „Ich frage zuerst, welches Problem das Aufteilen löst: Teams, die sich gegenseitig blockieren, Teile, die unterschiedlich skalieren müssen, oder Risiko beim Release. Dann ziehe ich Grenzen um Geschäftsbereiche, die ihre eigenen Daten besitzen, etwa Abrechnung oder Katalog, und ziehe einen nach dem anderen um, beginnend dort, wo der Gewinn klar und die Kopplung gering ist.“

Die ausführliche Antwort: Gute Service-Grenzen passen zu Geschäftsbereichen (Domain-Driven Design nennt sie Bounded Contexts) und zu den Teams, denen sie gehören, sodass die meisten Änderungen nur einen Service berühren. Jeder Service besitzt seine Daten; zwei Services, die sich Tabellen teilen, sind ein verkleideter einzelner Service. Das Aufteilen der Datenbank ist der schwierigste Teil; fang deshalb damit an, den Code im Monolithen zu trennen (ein modularer Monolith), und beobachte, welche Teile sich gegenseitig aufrufen. Microservices bringen Netzwerkaufrufe, Teilausfälle und mehr Betrieb; das Team braucht also zuerst gutes Deployment und Monitoring. Manche Systeme bleiben am besten ein gut strukturierter Monolith.

Schwache Antwort: „Ein Service pro Datenbanktabelle.“ Nachfrage: „Zwei vorgeschlagene Services rufen sich bei jeder Anfrage gegenseitig auf.“ Die Grenze ist falsch; leg sie zusammen oder verlege die Daten zu dem, der sie nutzt.

Wie setzt du Backend-Standards, denen viele Teams folgen, ohne sie auszubremsen?

Worauf sie achten: bei Rollen als Principal Engineer und Architekt Einfluss über Teams hinweg.

Kurze Antwort: „Ich schreibe ein paar Entscheidungen auf, die teamübergreifend zählen, etwa wie APIs versioniert werden, wie sich Services anmelden und was jeder Service loggen und messen muss, und baue sie in eine Service-Vorlage ein, damit der richtige Weg der einfache ist. Alles andere bleibt bei den Teams.“

Die ausführliche Antwort: Standards, denen niemand folgt, sind schlimmer als keine. Schreib jede Entscheidung als kurzen Eintrag mit ihren Gründen (ein Architecture Decision Record), damit man dem Grund widersprechen kann und nicht der Person. Biete einen gepflasterten Weg an: einen Vorlage-Service, in dem Anmeldung, Logging, Metriken, Health Checks und CI/CD schon eingerichtet sind. Prüfe neue Designs früh, solange Änderungen günstig sind, und miss die Übernahme. Akzeptiere Ausnahmen mit einer schriftlichen Begründung.

Schwache Antwort: „Jedes Design muss von mir freigegeben werden.“ Nachfrage: „Ein erfahrenes Team will eine neue Sprache einsetzen.“ Frag, welches Problem sie löst und wer sie nachts betreibt, und vereinbart einen Versuch mit Enddatum.

Dein Lebenslauf für diese Fragen

Der Interviewer fragt nach dem, was in deinem Lebenslauf steht. Gib jedem dieser Themen eine Zeile unter einer Stelle, mit einer Zahl, in den Wörtern der Anzeigen:

Skill	Schwache Zeile	Starke Zeile, mit Beleg
API-Design	REST-APIs entworfen.	Die öffentliche Bestell-API mit Idempotency Keys und Versionierung entworfen; doppelte Abbuchungen durch Wiederholungen auf null gesenkt.
Datenbanken	Datenbankoptimierung.	Die 5 langsamsten Abfragen über die Ausführungspläne gefunden; CPU-Last der Datenbank in der Spitze von 90 % auf 45 % gesenkt.
Queues	Asynchrone Verarbeitung.	Rechnungs-PDFs in einen RabbitMQ-Worker verlegt; Antwortzeit im Checkout um 600 ms gesenkt.
Observability	Monitoring und Logging.	Request-IDs, Tracing und Alarme auf die Fehlerrate für 12 Services eingeführt; die Ursache eines Vorfalls ist in Minuten statt Stunden gefunden.
Architektur	Microservices-Architektur.	Die Abrechnung mit eigener Datenbank aus dem Monolithen gelöst; Releases der Abrechnung täglich statt monatlich.

Bewerte deinen Lebenslauf dann an einem echten Backend-Job: Du siehst, auf welche dieser Punkte der Service angewiesen ist, an dem du arbeiten würdest, und welche dein Lebenslauf noch nicht mit einer Zahl belegt.

Das Wichtigste

Entwirf jeden Schreibzugriff so, dass er sicher wiederholt werden kann; Clients und Queues werden wiederholen.
Lass die Datenbank mit Transaktionen, bedingten Updates und Unique Constraints über die Korrektheit wachen.
Gib jedem Aufruf nach außen einen Timeout, wenige Wiederholungen und einen Ersatz.
Miss, bevor du skalierst: Die Grenze ist meist die Datenbank.
Für Senior-Rollen kommen Daten über Services hinweg, Systemdesign und Service-Grenzen dazu, die dem Geschäft folgen.

Häufige Fragen

Was wird im Vorstellungsgespräch als Backend-Entwickler am häufigsten gefragt?: API-Design, Datenbanken, Indizes und Transaktionen, Caching, Queues, Ausfälle zwischen Services, Sicherheit, Skalierung und Monitoring, und für Senior-Rollen Systemdesign und Service-Grenzen.
Gibt es eine Programmierrunde?: Meistens: eine Programmieraufgabe in deiner Sprache, oft mit Datenstrukturen, und manchmal eine kleine API, die du bauen sollst. Erklär dabei dein Vorgehen und deine Tests.
Muss ich Microservices kennen?: Du solltest wissen, was sie lösen und was sie kosten. Viele Teams betreiben einen gut strukturierten Monolithen, und Interviewer mögen Kandidaten, die sagen können, wann man nicht aufteilt.
Wie tief sollte mein Datenbankwissen sein?: Tief genug, um einen Ausführungsplan zu lesen, einen Index zu wählen, eine Transaktion zu erklären und mit zwei gleichzeitigen Schreibzugriffen umzugehen.
Wie bereite ich mich in einer Woche vor?: Sag die zwei ausgearbeiteten Antworten laut, übe ein Systemdesign laut mit einem Timer, lies den Ausführungsplan einer eigenen langsamen Abfrage und bereite je eine Geschichte vor: über einen Ausfall, eine Beschleunigung und ein Design, das du heute anders machen würdest.

So nutzt du diese Fragen

Was ein Backend-Entwickler können muss

APIs

Eine mobile App wiederholt eine Anfrage, wenn das Netz abbricht. Wie stellst du sicher, dass die Zahlung nur einmal passiert?

Wie änderst du eine API, ohne die Apps kaputtzumachen, die sie schon nutzen?

Datenbanken und Transaktionen

Wie macht ein Index eine Abfrage schnell, und wann macht ein neuer Index alles schlimmer?

Zwei Nutzer buchen im selben Moment den letzten Platz. Wie sorgt dein Service dafür, dass nur einer ihn bekommt?

Wie entscheidest du dich für einen neuen Service zwischen einer relationalen Datenbank und einer Dokumentendatenbank?

Caching, Queues und Ausfälle

Wo würdest du einen Cache einbauen, und wie verhinderst du, dass er alte Daten liefert?

Wann würdest du Arbeit in eine Queue legen, statt sie in der Anfrage zu erledigen?

Ein Service, den du aufrufst, wird langsam, und bald fällt auch deiner aus. Was tust du?

Sicherheit, Skalierung und Betrieb in Produktion

Wie melden sich Nutzer bei deiner API an, und wie weisen Services sich gegenseitig aus?

Dein Service muss in zwei Monaten zehnmal so viel Traffic wie heute verkraften. Wie bereitest du dich vor?

Viele Anfragen kommen gleichzeitig an. Wie geht deine Sprache damit um, und was geht zuerst aus?

Was loggst, misst und alarmierst du bei einem Backend-Service?

Fragen für Staff, Principal und Architekten

Eine Bestellung berührt den Bestell-, den Zahlungs- und den Lager-Service. Wie hältst du die Daten konsistent, ohne eine gemeinsame Transaktion?

Entwirf das Backend für Benachrichtigungen, die Millionen Nutzer per E-Mail und Push-Nachricht erreichen.

Du sollst einen großen Monolithen in Services aufteilen. Wie legst du die Grenzen der Services fest?

Wie setzt du Backend-Standards, denen viele Teams folgen, ohne sie auszubremsen?

Dein Lebenslauf für diese Fragen

Das Wichtigste

Häufige Fragen

Mehr zu diesem Beruf