yk.camelcase.work

Aktuelle Arbeiten

Aktuelle Produkte, von Anfang bis Ende gebaut. Jeder Eintrag nennt die technische Entscheidung, die ihn geprägt hat - nicht die Liste der Features.

Jedes der folgenden Projekte begann mit einem echten Problem. Ab da ist die Rolle immer dieselbe: Produktkonzept, Systemarchitektur, Implementierung, Infrastruktur, Deployment und Continuous Delivery - jedes Produkt entwickelt sich lange über sein erstes Release hinaus weiter.

DreamBank - Virtuelle Banking-Plattform im geschlossenen Kreislauf

DreamBank ist die Finanzschicht eines geschlossenen Spiele-Ökosystems: virtuelle Karten, Mehrwährungssalden, Überweisungen, Cashback, Sparen und virtueller Kredit - ohne jeden Weg hinaus in echtes Geld. Die Währungen sind fiktiv, die Buchhaltung nicht - sie läuft als doppelte Buchführung mit unveränderlichen Buchungen hinter einer Reihe von Go-Services. Das Designziel, auf das ich optimiert habe: Jede Saldoänderung lässt sich der Person erklären, der das Konto gehört.

Problem

DreamBank ist eines von mehreren Produkten im Dream-Ökosystem, neben DreamBox, DreamFarm und DreamMarket - und dasjenige, über das alle abrechnen. Das Ökosystem selbst entstand aus einer anderen Idee: Online-Shopping wird leicht zu einer Gewohnheit, die echtes Geld kostet, doch Studien legen nahe, dass die meiste Freude aus dem Suchen, dem Auswählen und dem Bezahlvorgang kommt, nicht aus dem Besitz. Dream behält dieses Erlebnis bei und nimmt ihm die Kosten - mit virtueller Währung, die nie zu echtem Geld wird. Damit sich das echt anfühlt, muss sich das Geld wie Geld verhalten - Karten, Salden, ein Verlauf - in allen Produkten zugleich.

Double-entry ledgerGo, PostgreSQLMulti-currency accountingclosed-loop fictional currenciesTransactional outboxat-least-once, idempotent consumersRisk and anti-abuse decisionsvelocity, reputation, holdsCard-first product modelvirtual cards, shared cards, receive detailsInstallable client, native-readyNext.js PWA, static export

Architektur

  • Doppelte Buchführung für Spielgeld. Jede Saldoänderung ist ein Journaleintrag, dessen Buchungen sich zu null summieren, gebuchte Zeilen sind unveränderlich, und Salden sind Projektionen, die sich aus den Buchungen neu aufbauen lassen. Eine gespeicherte Saldospalte wäre viel einfacher gewesen - und dauerhaft unerklärbar.
  • Ein Topf pro Karte, keine Wallet. Drei Karten in einer Währung sind drei unabhängige Salden, und Werte zwischen ihnen zu verschieben ist eine echte Überweisung. Ein gepoolter Saldo auf Nutzerebene ist ausdrücklich verboten, damit kein Ablauf stillschweigend einen erfindet.
  • Währungsübergreifende Bewegungen bleiben explizit. Jedes Ledger-Konto und jede Buchung trägt genau eine Währung, sodass keine Überweisung stillschweigend umrechnen kann. Eine währungsübergreifende Bewegung ist eine eigene Operation, die Angebot, Kurs, Kursversion und Ablaufzeit vor der Bestätigung festhält.
  • Prämien sind noch kein Geld. Cashback sammelt sich als Punkte in einem separaten Append-only-Journal und erreicht das Geld-Ledger nur über eine bestätigte Einlösung. Punkte werden erst gutgeschrieben, wenn das Rückbuchungsfenster geschlossen ist, sodass eine Erstattung keinen Punktestand ins Minus treiben kann.
  • Versuche zählen, nicht Erfolge. Velocity-Zähler werden erhöht, während eine Operation geprüft wird - vor der Entscheidung -, sodass auch abgelehnte Versuche zählen. Ich habe Genauigkeit als Aktivitätsprotokoll gegen Immunität gegenüber dem Austricksen von Schwellenwerten durch schnelle Wiederholungen eingetauscht.

Editron

Ein API-first-Dienst zur Texttransformation. Der eigene Web-Editor ist ein First-Party-Client derselben öffentlichen API und darf sie nicht umgehen - genau das hält die Integrationsschnittstelle ehrlich; die Verarbeitungs-Engine ist hinter einem internen Vertrag austauschbar, Mandantenfähigkeit, API-Keys, Kontingente und Nutzungsabrechnung sind von Anfang an mitgedacht, dazu kommt ein veröffentlichtes TypeScript-SDK.

Lernklang

Eine zugangsgeschützte Hörplattform zum Sprachenlernen mit einem Analyse-Dashboard für Schulen. Ein Image, drei Rollen: Geplante Aufgaben laufen in einem eigenen Container, sodass ein Neustart oder Skalieren der Web-App nie einen Job überspringt oder doppelt ausführt - und die Konfiguration wird beim Start validiert: Bei einer ungültigen Variable startet der Prozess gar nicht erst, statt in der Produktion still zu scheitern.

Herald

Themengesteuertes Sammeln, Verarbeiten und Ausliefern von Nachrichten. Die Deduplizierung greift bei der Auslieferung, pro Kanal über einen Content-Hash mit der URL als Fallback innerhalb eines gleitenden Zeitfensters, sodass syndizierte und live aktualisierte Artikel nie zweimal verschickt werden; jeder Artikel ergibt drei unabhängig erzeugte Formate, jedes mit der exakten Pipeline-Version versehen, die es erstellt hat - für Reproduzierbarkeit und Kostenabrechnung.

Kleinere Produkte und gezielte Experimente gehören zur selben Praxis: Mit ihnen lässt sich eine Idee, ein Interaktionsmuster oder ein neuer Workflow schnell validieren, bevor man sich auf ein größeres System festlegt.