Engineering-Arbeit
Ausgewählte Arbeit bei tyntec
Das sind sechs ausgewählte Beispiele aus einem größeren Aufgabenbereich bei tyntec. Aus Respekt vor der Vertraulichkeit von Kunden und Unternehmen halte ich die Details bewusst allgemein.
Number Verification API
Eine eventgesteuerte Java- und Spring-Boot-API, die Telefonnummern gegen externe Quellen prüft. Jede Datenart hat ihre eigene Caching-Regel, und ein Circuit Breaker mit Graceful Degradation verhindert, dass eine langsame Quelle den ganzen Ablauf blockiert. Die API ist Contract-first, und Kafka-Ereignisse verbinden sie mit der nachgelagerten Verarbeitung.
Routing-Konfiguration
Ein React- und TypeScript-Tool auf einem Kotlin- und Spring-Boot-Service, mit dem Operatoren Routing-Regeln und Prioritäten über HTTP und ENUM selbst verwalten, ohne einen Engineer zu fragen. Regeln werden als Daten gespeichert, getrennt von der Logik, die sie anwendet. Prioritätskonflikte erscheinen in der Oberfläche und werden im Backend erneut geprüft. Eventgesteuerte Kafka-Updates und Kafka Streams verarbeiten Änderungen; jede Änderung wird protokolliert, und der vorherige Stand lässt sich jederzeit wiederherstellen.
AWS-S3-Abgleichsautomatisierung
Eine Full-Stack-Automatisierung mit Java- und Spring-Boot-Backend, React- und TypeScript-Frontend sowie AWS-S3-Speicher. Sie verkürzte einen manuellen Abgleich von bis zu 48 Stunden auf unter eine Stunde und erzielte im ersten Jahr einen Return on Investment von 1.300 %.
ENUM-Lookup-API über DNS
Ein Java- und Spring-Boot-Microservice, der externe Kunden über DNS findet und kontaktiert, mit ENUM-Lookups von Nummer zu Dienst. Er braucht kein proprietäres SDK und keine besonderen Firewall-Regeln. Das Caching folgt den TTLs der Einträge. Fehler werden klassifiziert: Ein fehlender Eintrag ist ein harter Fehler, Timeouts werden mit exponentiellem Backoff wiederholt. Tests laufen gegen einen lokalen DNS-Server im Container, nie gegen Live-DNS.
Kafka-Abrechnung und Reporting
Eventgesteuerte Kafka-Pipelines verarbeiten täglich Millionen Nachrichten für Abrechnung und Reporting. Idempotente, multithreaded Consumer erhalten die Reihenfolge pro Kunde und verschieben fehlerhafte Ereignisse in Quarantäne. Prometheus- und Grafana-Dashboards zeigen Durchsatz, Verarbeitungszeit, Consumer-Lag und Dead Letters.
Verteilte CSV-Verarbeitung
Eine geplante, verteilte CSV-Datenaufnahme für mehr als 50 Länder, integriert mit verteilter Datenbank und Infrastruktur.
Zu sehen im ProjektMeridian
Wie alles läuft
Pipelines
Kafka-Pipelines verarbeiten täglich Millionen Nachrichten. Die Consumer sind idempotent, die Reihenfolge bleibt pro Kunde erhalten, und fehlerhafte Ereignisse gehen in eine Quarantäne, damit sie gesunden Traffic nie blockieren.
Observability
Jeder Service bekommt Metriken zu Requests, Fehlern und Dauer, Dashboards und Alerts mit einer verantwortlichen Person und einem Runbook.
Legacy
Außerdem verantworte ich eine produktive Legacy-Plattform mit: erst das Verhalten verstehen, dann Tests und Monitoring ergänzen und eine kleine Sache nach der anderen ändern.
Delivery und Daten
In dieser Arbeit werden Services als Docker-Images paketiert und mit Helm auf Kubernetes ausgerollt. PostgreSQL-Schemaänderungen werden mit Flyway verwaltet.
Wie ich arbeite
Ich baue Software, die echte geschäftliche Probleme löst. Ich arbeite nah an den Menschen, die den Prozess verantworten, lerne zuerst ihre Domäne kennen und verantworte die Lösung von Anfang bis Ende: bauen, ausliefern, in Produktion betreiben und so übergeben, dass das Team sie selbst verantworten kann.
Ich arbeite an Full-Stack-Software und KI – von produktiven Services bis zu Funktionen mit integrierten Modellen.
Forward Deployed als Grundhaltung
Full-Stack Software Engineering
Meine Arbeit umfasst Full-Stack-Systeme mit KI, KI-Prozessautomatisierung, Plattformintegration, Cloud-Infrastruktur und DevOps: Microservices und Datenpipelines mit Domain-Driven Design, API-Verträge, Datenbanken, Authentifizierung, CI/CD und die React-Frontends darauf, verantwortet vom ersten Gespräch bis zur Rufbereitschaft.
Forward Deployed ist für mich keine eigene Rolle. So betreibe ich Software Engineering: dort anfangen, wo die Arbeit tatsächlich passiert, und bleiben, bis es läuft.
Vorgehen
- 01
Dort zuhören, wo gearbeitet wird
Ich setze mich zu den Operatoren und Verantwortlichen, die den Prozess betreiben, denn sie wissen, wo er wirklich hakt.
- 02
Den Umfang festhalten
Was wir lösen, woran wir den Erfolg erkennen und was wir vorerst bewusst weglassen.
- 03
Den kleinsten funktionierenden Ausschnitt bauen
Ein echter Ablauf durch alle Schichten, Ende zu Ende, bevor irgendetwas poliert wird.
- 04
Nachweisen
Tests, Abnahmekriterien mit den künftigen Nutzern und Lasttests dort, wo Last eine Rolle spielt.
- 05
Ausliefern und betreiben
CI/CD nach Kubernetes, Dashboards und Alerts ab dem ersten Tag, und für das, was ich ausliefere, habe ich Rufbereitschaft.
- 06
Übergeben und zurückspielen
Dokumentation und Runbooks, damit andere es betreiben können. Was wiederverwendbar ist, fließt in die Plattform zurück, statt eine Einzellösung zu bleiben.
In Produktion
KI-gestützte Entwicklung
Bei tyntec nutze ich GitHub Copilot und Claude jeden Tag, als freigegebene Tools im Rahmen der Unternehmensregeln. Sie machen mich schneller bei den Teilen der Arbeit, die nie das Schwierige waren.
Ich verantworte jede Zeile, die ich merge, egal wer sie entworfen hat. Deshalb ist mein Ablauf darauf ausgelegt, die Ergebnisse zu prüfen, statt ihnen zu vertrauen: Ich lese jede Zeile, führe die Tests aus und prüfe den Diff, als hätte ihn eine Kollegin geschrieben.
Wofür ich sie nutze
- Unbekannten Code verstehen
- Boilerplate
- Testentwürfe
- Dokumentation
- Mechanische Refactorings
Wo ich mich nicht auf sie stütze
- Architektur- und Abwägungsentscheidungen
- Authentifizierung und sicherheitskritischer Code
- Alles, was ich nicht überprüfen kann
Grenzen
- Nur freigegebene Tools, im Rahmen der Unternehmensregeln.
- Keine Geheimnisse, Kundendaten oder personenbezogenen Daten in Prompts.
- Nichts wird gemergt ohne bestandene Tests und menschliches Review.
In eigenen Projekten
AI Engineering – vom Workflow bis zum Produkt
Ich beginne mit dem Problem und entscheide dann, ob eine feste Regel, ein bestehendes Modell oder ein eigens trainiertes Modell am besten passt. Wo KI sinnvoll ist, baue ich Prüfungen und Schutzmaßnahmen darum herum – nicht nur einen Prompt.
Das Modell wird in ein Produkt integriert und anhand einer klaren Vergleichsbasis bewertet. Es bleibt nur, wenn es messbar hilft, und muss denselben Zuverlässigkeitsanspruch erfüllen wie meine produktiven Systeme.
Vorgehen
- 01
Die Aufgabe verstehen
Wer braucht was, wie läuft der Prozess heute ab und was würde ein Fehler kosten?
- 02
Den einfachsten Ansatz wählen
Eine feste Regel nutzen, wenn sie reicht; ein Modell nur dort einsetzen, wo es einen Mehrwert bringt.
- 03
Modell auswählen oder trainieren
Ein bestehendes Modell verwenden, wenn es passt; ein eigenes trainieren, wenn Aufgabe und Daten es rechtfertigen.
- 04
Sicher integrieren
Strukturierte Ausgaben validieren, Tool-Berechtigungen im Code begrenzen und verhindern, dass nicht vertrauenswürdige Eingaben Aktionen auslösen.
- 05
Menschen behalten die Kontrolle
Ein Mensch prüft folgenreiche Aktionen; Fehler werden abgelehnt, sicher wiederholt oder eskaliert.
- 06
Im Produkt messen
An einer Vergleichsbasis evaluieren, Entscheidungen nachvollziehen sowie Kosten, Latenz und Qualität überwachen. Das Modell bleibt nur, wenn es messbar hilft.
LLM-Toolkit
Zu sehen inMeridian Masterarbeit
Software · KI-gestützt · KI
Systemdesign- und Engineering-Prinzipien
Dieselben Engineering-Regeln gelten, ob der Code eine Kafka-Pipeline betreibt, von einem Assistenten stammt oder als Agent handelt. Jede Karte zeigt, für welche Bereiche sie gilt.
Plattformen und Integrationen
Die Übertragung pro Integration wählen
Kafka, wo Produzenten und Konsumenten entkoppelt bleiben oder Events erneut abspielen müssen; einfaches REST, wo der Aufrufer sofort eine Antwort braucht.
- Software
- KI
Fehler langweilig machen
Idempotente Konsumenten, Retries mit Backoff und ein Dead-Letter-Topic, damit eine fehlerhafte Nachricht geparkt wird statt verloren zu gehen.
- Software
- KI
Zuerst der Vertrag
Der OpenAPI-Vertrag wird vor dem Code abgestimmt, einschließlich der öffentlichen API-Spezifikationen, auf die Integratoren aufbauen.
- Software
- KI-gestützt
- KI
Identität an einer Stelle
Keycloak mit OAuth2 und OpenID Connect statt Authentifizierungslogik, die über die Services verstreut ist.
- Software
- KI
Was nicht im Dashboard ist, läuft nicht
Metriken zu Anfragen, Fehlern und Dauer, Dashboards und Alerts mit klarer Verantwortung, ab dem ersten Deployment.
- Software
- KI
Softwarearchitektur
Grenzen folgen der Domäne
Services werden nach Domain-Driven Design geschnitten, damit jeder Service seine Daten besitzt und sich eigenständig ändern kann.
- Software
- KI
Alles prüfen, was zurückkommt
Ein Kafka-Event, eine Partnerantwort oder eine LLM-Antwort: Nichts gilt als vertrauenswürdig, bevor es geprüft wurde.
- Software
- KI-gestützt
- KI
Die Entscheidung festhalten
Optionen, Abwägungen und Begründung in einer kurzen Notiz, die das Team später wiederfindet.
- Software
- KI-gestützt
- KI
Bewährt, bis das Gegenteil belegt ist
Bewährte Werkzeuge und Muster, solange es keinen messbaren Grund für etwas Neues gibt.
- Software
- KI-gestützt
- KI
Erst kapseln, dann ersetzen
Altsysteme bekommen zuerst eine Schnittstelle und Tests, dann einen schrittweisen Austausch, eine kleine Änderung nach der anderen.
- Software
- KI-gestützt
In der Arbeit zu sehen
Jede Projektseite zeigt diese Schritte an einem echten Projekt, mit ehrlichem Status.