Felix Wahl - .NET Backend Engineer. Verteilte Systeme, Reliability, Consistency: solide Grundlagen, auf denen sich bauen lässt.
Gerade wächst daraus etwas Neues. Ich arbeite mich in LLMs und AI Engineering ein, aufbauend auf dem Backend. Hier sammle ich, was ich dabei lerne: Überlegungen hinter Entscheidungen, offene Fragen und die Projekte, an denen ich das ausprobiere. Vieles davon ist noch unfertig. Ich schreibe es vor allem für mich selbst auf - und für jeden, dem es weiterhilft.
Eine .NET 10 Backend-Referenz, gebaut um striktes Layering: compiler-enforced Boundaries, zwei austauschbare Persistence-Adapter und result-basiertes Error Handling - jede architektonische Entscheidung als ADR dokumentiert. Der AI-Agent vereint Tool Calling, SSE-Streaming und RAG in einem Agentic Loop: zwölf Tools, hybrides Retrieval (semantisch + Keyword via RRF), Knowledge-Base-Antworten mit zitierten Quellen und einem Grounding-Check gegen Halluzination. Eine Guard-Pipeline rate-limitet und budgetiert jeden Tool-Aufruf; ein autonomer Ticket-Worker arbeitet ungefragt weiter, legt aber jede folgenreiche Entscheidung einem Menschen vor. Alles als Edge-Adapter ausschließlich durch die bestehenden Command-Handler, die Domain kennt kein LLM.
Tenant-aware Quota- und Rate-Limiting-Backend für SaaS-APIs. Drei unabhängig deploybare .NET 10 Services - Plans, Enforcement, Usage - mit Redis, Redpanda (Kafka API) und Keycloak OIDC. V1 (Backend) released. V2 (Angular Frontend) in Planung.
Eine .NET 10 Import-Pipeline, gebaut um Reliability: Outbox Pattern, strikte Domain State Machine, idempotente Verarbeitung und eine config-switchable Dispatch-Strategie - jede Design-Entscheidung auf Korrektheit und Nachvollziehbarkeit ausgerichtet.
Ingestion-Service für Pegelstand-Telemetrie von Häfen mit threshold-basiertem Sturmflut-Alerting - orientiert an Hamburgs WADI-Warnsystem (gestuft: warning ab 4,50 m, severe ab 5,50 m über NN). Eine Reading-Quelle - wahlweise Simulator (Composite-Level-Modell) oder der echte WSV/PEGELONLINE-Elbe-Feed, per Switch beim Start gewählt - liefert Readings; ein Ingestion-Service konsumiert über RabbitMQ mit Dead-Letter-Handling und gestufter, trend-aware Threshold-Evaluation; ein read-only Angular Dashboard zeigt Pegel, Alarmstufen und Trends als banded Area-Charts. Seit v1.2.0 mit echten Hamburger Elbe-Pegeln (St. Pauli, Bunthaus, Over, Zollenspieker; cm → NHN-Mapping, conditional polling); v1.3.0 (Juni 2026) macht die Frische der Werte ehrlich lesbar - Messwert-Alter statt Poll-Alter, Stale erst wenn der Daten-Zufluss aussetzt. Dazu Alert-Event-Publishing über Fanout-Exchange, OpenTelemetry-Tracing und zwei verifizierte Deployment-Pfade (Kubernetes + Argo CD, Azure Container Apps).
Der Intake-Assistent legt Tickets an, ohne die bestehenden zu kennen - fünfmal derselbe Druckerausfall, fünf Tickets. Die Lösung ist Retrieval. Die interessanten Fragen sind, wo die Vektoren wohnen und wer entscheidet, wann gesucht wird.
Ein Claude-Modell legt Tickets an - per Tool Calling, live gestreamt. Die Frage dahinter ist eine Platzierungsfrage: Wo wohnt ein LLM in einer Clean Architecture?
Aus einem Fenster von Pegelmesswerten wird eine Stufe - normal, warning, severe. Sechs Entscheidungen, die alle in dieselbe Richtung ziehen: Zuverlässigkeit.
Der V2-Scope steht. Ein Admin-Frontend plus Demo-Widget für den Hot Path - Angular statt React, BFF statt Token im Browser, und ein vertikaler Slice statt Feature-Liste.
Was beim Bauen eines Quota- und Rate-Limiting-Backends hängen geblieben ist - und was nicht.
MetricGate wurde solo, nebenbei und mit Claude Code als primärer Implementierungshilfe gebaut. Warum ich Kalenderschätzungen aus den Planungsdocs gestrichen habe, wie ich den Aufwand über Commit-Zeitstempel messe - und was die Geschwindigkeit kostet.