You (Katja)

Hi David, willkommen zurück. Danke, dass du noch mal gekommen bist. Kaffee?

🌐

David

Hi Katja. Ja, bitte, schwarz ist gut. Danke, dass ich hier sein darf.

🌐

You (Katja)

Also, wie du aus der E-Mail weißt, ist heute die technische Runde. Wir gehen durch einige deiner bisherigen Arbeiten, machen dann eine System-Design-Diskussion, und am Ende hast du Zeit für Fragen. Es ist keine Trickprüfung. Mich interessiert mehr, wie du denkst, als perfekte Antworten.

🌐

David

Das klingt gut. Ich bin ein bisschen nervös, muss ich zugeben, aber auf eine gute Art.

🌐

You (Katja)

lacht Das ist normal. Lass uns mit etwas anfangen, das du gut kennst. In deinem ersten Gespräch hast du erwähnt, dass du die Migration eines Monolithen zu Microservices in deiner aktuellen Firma geleitet hast. Kannst du mich da durchführen?

🌐

David

Klar. Also, ich arbeite für eine Online-Versicherungsplattform. Als ich angefangen habe, war das ganze System eine große Anwendung. Jedes Deployment hat etwa zwei Stunden gedauert, und wenn ein Teil ausgefallen ist, war alles down. Zu Spitzenzeiten, wie am Jahresende, war das ein echtes Problem.

🌐

You (Katja)

Wie groß war das Team?

🌐

David

Etwa fünfzehn Entwickler. Meine Rolle war es, die Migration zu planen und ein Team von vier Leuten zu leiten. Wir haben entschieden, nicht alles auf einmal neu zu schreiben, weil das meistens der Punkt ist, an dem solche Projekte scheitern. Stattdessen haben wir das sogenannte Strangler-Pattern verwendet. Wir haben einen Bereich nach dem anderen herausgenommen, angefangen mit dem, der die meisten Probleme verursacht hat: die Zahlungsabwicklung.

🌐

You (Katja)

Warum zuerst die Zahlungen? Das klingt riskant.

🌐

David

Es war riskant. Aber es war auch der Teil, der sich am häufigsten geändert hat und die meisten Vorfälle hatte. Der Nutzen war dort also am größten. Wir haben den neuen Zahlungsservice neben dem alten System aufgebaut und beide sechs Wochen lang parallel laufen lassen, um die Ergebnisse zu vergleichen. Erst als wir sicher waren, haben wir den Traffic umgeschaltet, schrittweise: zuerst fünf Prozent, dann fünfundzwanzig, dann alles.

🌐

You (Katja)

Und was waren die Ergebnisse?

🌐

David

Deployments für den Zahlungsservice sind von zwei Stunden auf etwa acht Minuten gesunken. Vorfälle in diesem Bereich sind in den nächsten sechs Monaten um etwa siebzig Prozent gesunken. Und vielleicht die größte Veränderung: Das Team wurde selbstbewusster beim Releasen. Vorher hatten die Leute Angst, freitags zu deployen. lacht Jetzt machen sie es immer noch nicht, aber zumindest haben sie keine Angst mehr.

🌐

You (Katja)

lacht Weises Team. Was würdest du anders machen, wenn du es noch einmal machen würdest?

🌐

David

Gute Frage. Ich glaube, ich habe die Datenseite unterschätzt. Die Datenbank zu teilen war viel schwerer als den Code zu teilen. Wir hatten viele Tabellen, die zwischen verschiedenen Teilen des Systems geteilt wurden, und das Entwirren hat Monate länger gedauert als geplant. Nächstes Mal würde ich die Datenabhängigkeiten viel früher analysieren, bevor ich überhaupt Code schreibe.

🌐

You (Katja)

Das ist eine sehr ehrliche Antwort. Die meisten Leute sagen "nichts". Okay, lass uns zum System-Design übergehen. Stell dir vor, wir möchten ein Echtzeit-Tracking-System für Pakete bauen. Unsere Fahrer haben eine App, die ihren GPS-Standort sendet. Kunden möchten auf einer Karte sehen, wo sich ihr Paket befindet, live. Wir haben zu Spitzenzeiten etwa zwanzigtausend Fahrer auf der Straße. Wie würdest du das angehen?

🌐

David

Okay. Darf ich zuerst ein paar Fragen stellen, um die Anforderungen zu verstehen?

🌐

You (Katja)

Bitte, genau das möchte ich sehen.

🌐

David

Wie oft sendet die Fahrer-App ein Standort-Update?

🌐

You (Katja)

Sagen wir, alle fünf Sekunden.

🌐

David

Also, zwanzigtausend Fahrer, alle fünf Sekunden, das sind etwa viertausend Updates pro Sekunde. Und wie viele Kunden schauen gleichzeitig zu?

🌐

You (Katja)

Schwer zu sagen. Vielleicht hunderttausend zu Spitzenzeiten, am Tag vor Weihnachten.

🌐

David

Und wie genau muss es sein? Muss ein Kunde die exakte Position alle fünf Sekunden sehen, oder ist es okay, wenn sich die Karte etwas seltener aktualisiert?

🌐

You (Katja)

Interessante Frage. Was denkst du?

🌐

David

Ehrlich gesagt, glaube ich nicht, dass ein Kunde ein Fünf-Sekunden-Update braucht. Wenn sich der Transporter alle fünfzehn oder zwanzig Sekunden auf der Karte bewegt, ist das wahrscheinlich in Ordnung. Das würde die Last auf der Kundenseite stark reduzieren.

🌐

You (Katja)

Guter Punkt. Machen wir das so.

🌐

David

Okay. Also würde ich das System in zwei Teile trennen: die Eingabeseite, wo die Fahrer Daten senden, und die Ausgabeseite, wo Kunden sie lesen. Auf der Eingabeseite senden die Fahrer-Apps ihren Standort an eine API, die die Nachrichten in eine Message Queue legt, so etwas wie Kafka. So gehen die Nachrichten bei einem plötzlichen Anstieg nicht verloren. Sie warten einfach in der Queue.

🌐

You (Katja)

Und wer konsumiert sie dann?

🌐

David

Ein Verarbeitungsservice liest die Nachrichten und speichert die aktuelle Position jedes Fahrers in einem schnellen In-Memory-Speicher, wie Redis. Wir brauchen für die Live-Karte nur die aktuelle Position, also können wir es einfach halten. Für die Historie, falls wir sie später für Analysen brauchen, könnte ein anderer Consumer die Daten separat in eine Zeitreihendatenbank schreiben.

🌐

You (Katja)

Und die Kundenseite?

🌐

David

Wenn ein Kunde die Tracking-Seite öffnet, öffnet die App eine WebSocket-Verbindung. Der Server abonniert Updates für diesen bestimmten Fahrer und pusht die neue Position etwa alle fünfzehn Sekunden. Das ist viel effizienter, als wenn hunderttausend Clients den Server alle paar Sekunden fragen würden.

🌐

You (Katja)

Was passiert, wenn ein Fahrer in einen Tunnel fährt und für zwei Minuten die Verbindung verliert?

🌐

David

Dann sollte die App die Positionen lokal speichern und sie senden, wenn die Verbindung wieder da ist. Auf der Kundenseite würden wir einfach die letzte bekannte Position zeigen, vielleicht mit einem kleinen Hinweis "zuletzt aktualisiert vor zwei Minuten". Ich glaube, es ist besser, ehrlich zu sein, als eine falsche Position zu zeigen.

🌐

You (Katja)

Das gefällt mir. Und Datenschutz? Wir verfolgen die Standorte von Menschen.

🌐

David

Richtig, das ist wichtig. Kunden sollten die Position des Fahrers nur sehen, wenn ihr Paket nahe ist, vielleicht für die letzten paar Stopps. Nicht die ganze Route. Und sobald die Lieferung abgeschlossen ist, sollte der Zugriff sofort enden. Die Position des Fahrers nach Feierabend sollte überhaupt nicht gespeichert werden.

🌐

You (Katja)

Sehr gut. Ehrlich gesagt, das ist ein solides Design. Eine letzte Frage. Unser Team arbeitet hauptsächlich in Go. Deine Erfahrung ist hauptsächlich in Java, richtig?

🌐

David

Ja, das stimmt. Ich habe Go in ein paar Nebenprojekten benutzt, aber nicht beruflich. Ich würde etwas Zeit brauchen, um richtig produktiv zu werden. Aber ich habe schon mal die Sprache gewechselt. Ich habe eigentlich mit PHP angefangen. Ich glaube, die Konzepte sind wichtiger als die Syntax.

🌐

You (Katja)

Da stimme ich zu. Wir würden dir für die ersten Monate einen Mentor geben. Okay, das war's von meiner Seite. Was möchtest du wissen?

🌐

David

Danke. Ich würde gerne verstehen, wie das Team arbeitet. Wie handhabt ihr die Rufbereitschaft?

🌐

You (Katja)

Jeder Entwickler ist eine Woche von sechs in Bereitschaft. Wir bezahlen extra dafür. Und wir haben eine Regel: Wenn jemand nachts geweckt wird, beheben wir die Ursache im nächsten Sprint. Keine Ausnahmen.

🌐

David

Das ist eine gute Regel. Und wie entscheidet ihr, was ihr baut? Haben Entwickler Einfluss auf die Roadmap?

🌐

You (Katja)

Ziemlich viel. Wir haben eine vierteljährliche Planungssitzung, in der Entwickler Vorschläge präsentieren. Etwa zwanzig Prozent unserer Zeit fließt in technische Verbesserungen, die Entwickler selbst wählen.

🌐

David

Das freut mich zu hören. Und letzte Frage: Wie sieht Erfolg für diese Rolle nach sechs Monaten aus?

🌐

You (Katja)

Nach sechs Monaten möchte ich, dass du einen Service komplett besitzt, dich in Go wohlfühlst und mindestens einen Junior-Entwickler mentorst. Du wärst der zweite Senior-Engineer in einem Team von sieben.

🌐

David

Das klingt genau nach der Rolle, die ich suche.

🌐

You (Katja)

Gut zu hören. Wir melden uns innerhalb einer Woche. Danke, David. Das hat mir Spaß gemacht.

🌐

David

Mir auch. Danke, Katja. Und danke für den Kaffee.

🌐

Show all translations

Finish dialogue ✓

0 words saved