Thema: architecture
-
Pipeline, Fan-out, Orchestrator und Kritikergremium: welches Multi-Agenten-Muster zu welcher Aufgabe passt
Eine Pipeline passt zu Aufgaben mit einer festen Abfolge von Transformationsschritten; paralleler Fan-out passt zu unabhängigen Teilfragen oder zu mehrfachen Versuchen, über die abgestimmt wird; ein Orchestrator mit Workern passt zu Aufgaben, deren Zerlegung erst zur Laufzeit bekannt ist; ein Kritikergremium passt zu Ergebnissen, die anhand mehrerer Kriterien geprüft werden müssen; jedes Muster vervielfacht die Tokenkosten und fügt eine Koordinationsschicht hinzu, die selbst scheitern kann.
-
DACI und RACI für technische Entscheidungen: eine genehmigende Person, benannte Mitwirkende
DACI benennt eine treibende Person, die die Entscheidung vorantreibt, eine einzige genehmigende Person, die sie trifft, Mitwirkende, die eine Stimme, aber kein Stimmrecht haben, sowie informierte Parteien, die vom Ergebnis erfahren; RACI weist Aufgaben die Rollen verantwortlich, rechenschaftspflichtig, konsultiert und informiert zu. Beide funktionieren für technische Entscheidungen, wenn die Rollen vor Beginn der Diskussion schriftlich festgelegt werden.
-
.NET-Konventionen für Dependency Injection: Lifetimes, Scopes und die Captive-Dependency-Falle
Microsoft.Extensions.DependencyInjection registriert Dienste auf einer IServiceCollection mit der Lifetime transient, scoped oder singleton und injiziert sie über öffentliche Konstruktoren; die dokumentierten Regeln lauten, nie einen scoped-Dienst in einen Singleton zu injizieren, den Container das entsorgen zu lassen, was er selbst erzeugt hat, Service-Locator-Aufrufe zu vermeiden und Scopes zu validieren, damit gefangene Abhängigkeiten (captive dependencies) schon beim Start scheitern, statt Zustand über Anfragen hinweg durchsickern zu lassen.
-
Event Sourcing und CQRS: was sie bringen und was sie kosten
Event Sourcing speichert jede Zustandsänderung als unveränderliches Ereignis und leitet den aktuellen Zustand durch Replay ab; CQRS trennt das Schreibmodell von den Lesemodellen. Beide bringen Nachvollziehbarkeit und Flexibilität auf Kosten von Komplexität und schliesslicher Konsistenz.
-
Go oder Rust für einen neuen Dienst wählen: ein Entscheidungsverfahren ohne Benchmarks
Die Wahl zwischen Go und Rust für einen Dienst anhand dokumentierter Spracheigenschaften und Teambeschränkungen treffen statt anhand von Benchmark-Folklore: Speicherverwaltungsmodell, Fehler- und Nebenläufigkeitsstil, Form der Arbeitslast, die Bibliotheken, mit denen der Dienst sprechen muss, und wer ihn in zwei Jahren pflegen wird.
-
Technische Schulden als bewusste Entscheidung mit Buchführung
Cunninghams Metapher: Nicht ganz richtiger Code ist ein Kredit, jede Minute Mehrarbeit daran ist der Zins. Die Metapher trägt nur, wenn die Schuld bewusst aufgenommen, notiert und regelmässig bewertet wird; als Sammelbegriff für alles Unschöne oder als Entschuldigung für Schlamperei ist sie wertlos.
-
Ein Werkzeug oder eine Skill mit einem Entscheidungsmodell auswählen: Choice zum Rangieren, Noul zum Enthalten
Warum eine Choice über Kandidatenwerkzeuge eine relative Frage beantwortet (welcher Kandidat passt am besten), während ein Noul pro Kandidat eine absolute Frage beantwortet (braucht dieser Zug überhaupt ein Werkzeug), und wie das Skill-Vorschlags-Kochbuch von TypeSafe beides über einen Katalog von 182 Skills kombiniert: eine Anfrage rangiert alle, eine zweite liest die obersten drei und kann alle drei ablehnen.
-
Durchgang durch einen Datei-Upload-Dienst: Tickets direkt zum Speicher, asynchrones Scannen und Kontingente
Ein Design-Durchgang für Uploads, die an den Anwendungsservern vorbeigehen: ein Ticket, das Kontingent reserviert und eine signierte Upload-URL zurückgibt, ein Abschlussschritt, der das gespeicherte Objekt verifiziert, ein Scan-Worker, der es freigibt oder löscht, Lebenszyklusregeln für abgebrochene Uploads sowie ein Statusmodell, das jedes gespeicherte Objekt erklärt.
-
Durchgang durch einen Benachrichtigungsdienst: Kanäle, Präferenzen, Zustellversuche und Wiederholungen
Ein Entwurfsdurchgang für einen mehrkanaligen Benachrichtigungsdienst: eine Ingest-API mit Idempotenzschlüssel, ein Router, der nach Prüfung der Präferenzen eine Benachrichtigung in Zustellungen je Kanal auffächert, Warteschlangen und Wiederholungspläne pro Kanal, Callback-Verarbeitung für ungültige Tokens und was zurückgestellt werden sollte.
-
Abgeleitete Daten in PostgreSQL speichern: generierte Spalten versus materialisierte Views
Eine generierte Spalte leitet einen Wert pro Zeile allein aus dieser Zeile ab, entweder virtuell (beim Lesen berechnet) oder gespeichert (beim Schreiben berechnet), und darf nur unveränderliche Ausdrücke verwenden; eine materialisierte View speichert das Ergebnis einer beliebigen Abfrage und ist nur so aktuell wie ihr letztes REFRESH. Gespeicherte generierte Spalten für Normalisierung je Zeile verwenden, die indiziert werden soll, materialisierte Views für teure Aggregate, die nachhinken dürfen, und eine gepflegte Zusammenfassungstabelle, wenn keines von beidem passt.
-
Agentengedächtnis gestalten: was dauerhaft gespeichert, was zusammengefasst und was vergessen wird
Das Gedächtnis eines Agenten hat drei Ebenen: das Kontextfenster, ein Aufgaben-Notizblock und ein dauerhafter Speicher über Sessions hinweg; pro Eintrag entscheiden, zu welcher Ebene er gehört, das dauerhafte Gedächtnis klein und überprüfbar halten und löschen, was nicht mehr zutrifft.
-
Server-Sent Events im Vergleich zu WebSockets
Server-Sent Events streamen Textereignisse vom Server zum Client über gewöhnliches HTTP mit automatischer Wiederverbindung und Last-Event-IDs; WebSockets bieten einen bidirektionalen, binärfähigen Kanal mit eigenem Protokoll. SSE für einseitige Aktualisierungen wählen, WebSockets, wenn der Client häufig senden muss.
-
Enthaltung als Agent: wenn Nicht-Handeln die richtige Ausgabe ist
Der Ausgaberaum eines Agenten sollte für jede automatisierte Aktion ein bewusstes «nicht entschieden» enthalten: was Enthaltung ist, warum ein Klassifikator oder Agent ohne sie jeden unklaren Fall in eine falsche Aktion verwandelt, und wie sich Enthaltung durch explizite Optionen, Konfidenz-Untergrenzen, einsatzabhängige Schwellenwerte und einen Weg für das Enthaltene einbauen lässt.
-
Wann lohnt sich clientseitiges Routing noch, jetzt, da Browser bfcache, Prerendering und dokumentübergreifende View Transitions bieten?
Offene Frage: In-Page-Router wurden eingeführt, um vollständige Seitenaufrufe zu vermeiden, auf Kosten von Shell-Auslieferung, 404-Behandlung, Scroll- und Fokus-Wiederherstellung und eines Bundles, das zuerst eintreffen muss; der Back/Forward-Cache, die Speculation-Rules-API und dokumentübergreifende View Transitions adressieren die ursprünglichen Beweggründe inzwischen auf Mehrseiten-Websites. Für welche Websites und Interaktionsmuster gewinnt ein In-Page-Router noch messbar?
-
Ab welcher Repository-Grösse brauchen Teams Monorepo-Build-Werkzeuge über blosses Git hinaus?
Offene Frage: Sparse Checkout, Partial Clone und Per-Verzeichnis-CI-Filter decken die erste Phase eines wachsenden Einzelrepositorys ab; bei welcher Grösse, Teamzahl oder Build-Zeit haben Teams festgestellt, dass ein Build-Graph-Werkzeug mit Remote-Caching nötig wurde, und was kostete der Übergang?
-
Zwischen Threads, Prozessen und asyncio für eine Python-Arbeitslast wählen
Zuerst den Hot Path klassifizieren: Warten auf I/O passt zu asyncio (viele Verbindungen, asynchrone Bibliotheken) oder zu einem Thread-Pool (wenige blockierende Aufrufe); reine Python-CPU-Arbeit braucht Prozesse oder einen Free-Threaded-Build; nativer Code, der das GIL freigibt, kann Threads nutzen. Jeden Pool begrenzen, die Prozess-Startmethode explizit wählen und den Abschaltpfad schreiben.
-
URL-Shortener im Durchgang: Schlüsselerzeugung, Weiterleitungsstatus und Missbrauchskontrollen
Ein Entwurfsdurchgang für einen URL-Shortener: zufällige Base62-Schlüssel mit Kollisionswiederholung, ein Weiterleitungspfad, der genau einen Cache und einen Speicher berührt, 302 statt 301, wenn Ziele widerrufbar und zählbar bleiben müssen, Missbrauchsprüfungen bei der Erstellung, und eine Liste dessen, was zuerst nicht gebaut werden sollte.
-
Architecture Decision Records (ADR)
Ein Architecture Decision Record hält eine bedeutsame Entscheidung mit ihrem Kontext, der Entscheidung selbst, ihrem Status und ihren Konsequenzen in einer kurzen, beim Code abgelegten Datei fest.
-
Caching in Anwendungen: Ablaufzeiten, Invalidierung und Schutz vor dem Ansturm
Ein Anwendungs-Cache hält abgeleitete Daten und darf jederzeit verloren gehen; korrekt bleibt er nur durch bewusste Invalidierung: Ablaufzeit je Datenklasse, Löschen statt Überschreiben beim Schreiben, Versionskennung im Schlüssel und eine Sperre gegen gleichzeitiges Nachladen heisser Schlüssel.
-
ETL versus ELT: Wo die Transformation läuft und was das ändert
ETL transformiert Daten in einer separaten Engine, bevor sie ins Ziel geladen werden; ELT lädt zuerst die Rohdaten und transformiert sie mit der eigenen Verarbeitung des Zielspeichers. Die Wahl entscheidet, wo Rechenleistung bezahlt wird, welche Rohdaten im Warehouse landen und wie leicht sich eine Transformation erneut ausführen lässt.
Maschinenlesbar: JSON