Paweł D.-Backend-Engineer • Zahlungs- & ereignisgesteuerte Systeme

Selbstständiger Auftragnehmer für Fintech-, Commerce- und Marketingplattformen.

Geschäftskritische Zahlungsdienste auf einer Plattform, die Millionen genehmigter Transaktionen pro Monat verarbeitet

Zahlungen und Auszahlungen — idempotente Verarbeitung von Anfragen, Exactly-once-Verarbeitung, vollständiger Audit-Trail für jeden Statuswechsel

Ledger und Abstimmung — Beträge in Minor Units, automatischer Abgleich interner Datensätze mit den Abrechnungen der Anbieter

KYC- und Onboarding-Abläufe sowie Reporting und Datenpipelines für Transaktionsdaten

Überschneidende Arbeitszeiten mit dem US-Team; verantwortlich für Integrationen, Ledger, Compliance und Reporting statt nur für einen kleinen Teilbereich

Einziger Engineer im Produkt — eine Engineering-Abteilung in einer Person mit Verantwortung für Architektur, AWS-Infrastruktur, Auslieferung und Zuverlässigkeit im Betrieb

Zentrale Seitenladezeit von 5s auf 2s reduziert, während der Traffic um das 10-Fache wuchs

Datenbankauslastung bei demselben 10-fachen Wachstum von dauerhaft am Instanzlimit auf ~30% gesenkt

Lock Contention (6s Sperre auf Zeilenebene) analysiert und beseitigt, wodurch horizontale Skalierung unwirksam war — zehn Instanzen konnten vor der Behebung der Konkurrenz um Sperren nicht mehr als 2 Webhooks/s verarbeiten

Veröffentlichung von Ereignissen, die vor dem Transaktions-Commit stattfand, behoben und damit Race Conditions zwischen Services bei veralteten Lesezugriffen beseitigt

Eine zentrale Verkaufskomponente von PHP nach Go neu geschrieben und in Produktion gebracht — aufgrund des Nebenläufigkeitsmodells nach den Arbeiten an der Lock Contention ausgewählt, da PHPs Shared-Nothing-Worker-Modell hier nicht geeignet war

Auftragsverarbeitung als asynchrone 7-Schritte-Kette über eine langsame, unzuverlässige Ereignisquelle eines Drittanbieters neu konzipiert — Idempotenz an jedem Übergang, Wiederholungen sowie Umgang mit Duplikaten und Ereignissen in falscher Reihenfolge

Direkt mit Gründern gearbeitet — Geschäftsziele in Umfang, Schätzungen und Abwägungen übersetzt und in nicht-technischen Begriffen erklärt

Verantwortung für den gesamten SDLC: CI/CD, Monitoring und Alerting (CloudWatch), Incident Response, Härtung nach Vorfällen

Über den vereinbarten Umfang hinaus: die ersten produktiven LLM-Funktionen der Plattform vorgeschlagen und umgesetzt

Laravel- und Symfony-Backend für eine Plattform mit 2.5M+ monatlich aktiven Nutzern

WMS-Integration zur Verarbeitung von 150,000+ Bestellungen täglich

Redis-Caching und verteilte Sperren zur Beseitigung von Race Conditions während Flash Sales mit 50,000+ gleichzeitigen Nutzern

AWS — ECS, RDS, Lambda, CloudWatch und Auto Scaling zur Bewältigung von 3-fachen Werbekampagnen-Spitzen

Newsletter-Plattform für 500,000+ Abonnenten mit 2–3M monatlich versendeten E-Mails und Echtzeit-Tracking

Asynchrones PHP mit Temporal und Swoole — Versandzeit von Kampagnen um 60% reduziert

Produktionsarbeit mit MySQL/MariaDB, PostgreSQL und MSSQL — Strategien für Abfragen und Indizes, Transaktionsisolationsebenen, Analyse von Deadlocks, Verarbeitung großer Datenmengen mit minimalem Speicherbedarf

Behat (E2E) und PHPUnit, dauerhaft mehr als 60% Abdeckung, TDD für neue Funktionen

Vier produktive LLM-Funktionen ausgeliefert — Extraktion von Dokumentdaten, Support-Automatisierung, Inhaltserstellung

Die Pipeline um das Modell herum aufgebaut, nicht nur um den API-Aufruf — asynchrone Verarbeitung über Warteschlangen (RabbitMQ / Temporal), strukturierte Ausgaben mit Schema-Validierung, Wiederholungen und Fallbacks, damit Modellfehler niemals den Geschäftsablauf unterbrechen

Regressionstests für Prompt-Änderungen; Prompts wie Produktionscode versioniert. Kosten und Latenz durch Antwort-Caching, aufgabenspezifische Modellauswahl und Token-Budgetierung kontrolliert

Täglicher KI-gestützter Entwicklungsprozess (Claude Code) — agentisches Refactoring in Legacy-Codebasen, Testgenerierung, automatisierte erste Review-Runde