Zum Inhalt springen
serdjukow.eu

Sergej Serdjukow, Software-Entwickler, Berlin, Deutschland

Software, die weiterläuft, wenn etwas schiefgeht.

Skalierbare Webanwendungen und eventgetriebene Systeme auf AWS – gebaut für Retries, Duplikate und Lastspitzen.

  • Next.js
  • TypeScript
  • AWS
  • Serverless
  • AI
Engineering Stories ansehenKontakt aufnehmen

Dekorative Animation: eine simulierte eventgetriebene Pipeline. Events fließen von Producern über eine API und eine Queue zu einem Pool aus sechs Workern und in einen Store; fehlgeschlagene Events werden mit Backoff wiederholt und nach drei Versuchen in eine Dead-Letter-Queue verschoben.

Fokus

Schwerpunkte

  • Asynchrone Verarbeitung

    Queues, Scheduler und Webhooks, die lang laufende Jobs zuverlässig durchlaufen lassen – mit Retries, Dead-Letter-Queues und Reconcilern.

  • AWS Serverless

    Amplify Gen 2, AppSync, Lambda, DynamoDB, SQS und EventBridge Scheduler im Produktivbetrieb.

  • KI im Produkt

    LLM-Funktionen in echten Workflows: KI-bewertete Websites, generierte E-Mails und LLM-gestützte Terminplanung, geprüft durch deterministische Regeln.

  • Anspruchsvolle Frontends

    Oberflächen mit React und Next.js für datenintensive Workflows, mit Live-Status über Subscriptions.

Wie Systeme in Produktion bestehen

Anatomie eines zuverlässigen Systems

Sechs Muster, die ein eventgetriebenes System korrekt halten, wenn Aufrufe scheitern, Nachrichten doppelt ankommen und die Last sprunghaft steigt.

  1. Systemdiagramm: Die API bestätigt Anfragen sofort, die Queue puffert sie; zwei Worker arbeiten sie im eigenen Tempo ab.

    01 / 06

    Schnell annehmen, asynchron verarbeiten

    Die API validiert die Anfrage, legt sie in eine persistente Queue und antwortet innerhalb von Millisekunden mit 202 Accepted. Langsame oder unzuverlässige Arbeit erledigen später Worker, die Nachrichten in ihrem eigenen Tempo abholen. Die Latenz für Aufrufer hängt nicht mehr von der langsamsten nachgelagerten Abhängigkeit ab.

    In der Praxis: Mit dem 202 eine Job- oder Event-ID zurückgeben, damit Clients das Ergebnis abfragen oder abonnieren können.

  2. Systemdiagramm: Eine Nachricht scheitert zweimal, wartet mit wachsendem Backoff und ist im dritten Versuch erfolgreich.

    02 / 06

    Retries mit Backoff

    Die meisten Fehler sind vorübergehend: ein gedrosselter Dienst, ein Timeout, eine abgebrochene Verbindung. Eine fehlgeschlagene Nachricht wird nicht gelöscht, sondern nach Ablauf des Visibility Timeouts wieder sichtbar und erneut verarbeitet. Exponentielles Backoff mit Jitter verteilt die Versuche, damit Retries eine angeschlagene Abhängigkeit nicht als synchrone Welle treffen.

    In der Praxis: Visibility Timeout deutlich über dem Worker-Timeout ansetzen (bei Lambda etwa das Sechsfache), sonst wird mitten in der Verarbeitung erneut zugestellt.

  3. Systemdiagramm: Eine Nachricht scheitert dreimal und landet in der Dead-Letter-Queue; der Alarm schlägt an, nach dem Fix folgt der Redrive.

    03 / 06

    Dead-Letter-Queue

    Manche Nachrichten werden nie erfolgreich sein: ungültige Daten, ein Bug, ein fehlender Datensatz. Nach maxReceiveCount Versuchen verschiebt die Queue sie in eine Dead-Letter-Queue, damit eine einzelne Poison Message weder den Rest blockiert noch Kapazität verbrennt. Der Fehler ist geparkt, nicht verloren: Ein Alarm schlägt an, die Ursache wird behoben, die Nachricht per Redrive erneut eingespielt.

    In der Praxis: Alarm auf DLQ-Tiefe > 0. Eine Dead-Letter-Queue, die niemand beobachtet, ist nur ein langsamerer Weg, Daten zu verlieren.

  4. Systemdiagramm: Dieselbe Nachricht wird zweimal zugestellt; der zweite Write findet den vorhandenen Key und bleibt ohne Wirkung.

    04 / 06

    Idempotenz

    Queues stellen mindestens einmal zu, und auch Clients wiederholen Anfragen; dieselbe Nachricht kommt also irgendwann doppelt an. Jede Nachricht trägt einen Idempotency Key, den der Worker per Conditional Write speichert; der Seiteneffekt passiert nur, wenn der Key neu ist. Das Duplikat wird geschluckt, das Ergebnis ist dasselbe wie bei einmaliger Zustellung.

    In der Praxis: In DynamoDB attribute_not_exists(pk) auf den Key: ein Conditional Write, keine Race Condition zwischen Lesen und Schreiben.

  5. Systemdiagramm: Eine Lastspitze füllt die Queue, während nur drei Worker-Slots laufen; der Rückstau baut sich gleichmäßig ab.

    05 / 06

    Backpressure und Concurrency-Limits

    Eine Lastspitze fängt die Queue ab, statt sie durchzureichen. Reserved Concurrency begrenzt, wie viele Worker gleichzeitig laufen, sodass die Datenbank oder eine Partner-API die gleichmäßige Last sieht, für die sie ausgelegt ist. Der Rückstau wächst kurz und baut sich dann ab: Nichts geht verloren, es dauert nur etwas länger.

    In der Praxis: Das Limit danach bemessen, was das nachgelagerte System verkraftet, nicht danach, was die Spitze verlangt.

  6. Systemdiagramm: Jede Komponente liefert Logs und Metriken; Alarme überwachen DLQ-Tiefe und das Alter der ältesten Nachricht.

    06 / 06

    Observability

    Asynchrone Systeme fallen leise aus: Die API antwortet weiter mit 202, während sich dahinter Nachrichten stauen. Strukturierte Logs mit Correlation ID machen den Weg einer Nachricht über Dienste hinweg nachvollziehbar; Metriken zeigen Durchsatz, Fehler und Queue-Tiefe. Alarme gehören auf die Symptome, die zählen: DLQ-Tiefe und das Alter der ältesten Nachricht.

    In der Praxis: Das Alter der ältesten Nachricht verrät einen hängenden Consumer auch dann, wenn die Queue-Tiefe bei wenig Traffic unauffällig bleibt.

Fallstudien

Engineering Stories

Probleme aus Produktivsystemen, die Abwägungen hinter der Lösung und was sich dadurch verändert hat.

Projekte

Ausgewählte Projekte

Produktivsysteme aus meiner Arbeit bei Formilo und ComonGames sowie einige Werkzeuge, die ich privat gebaut habe.

  • Formilo, seit 2025, Hauptentwickler

    Asynchrone Outreach-Plattform

    Produktivplattform auf AWS Amplify Gen 2. Sie findet Unternehmen, crawlt ihre Websites und bewertet sie per KI, erzeugt personalisierte E-Mails und steuert geplante Kampagnen mit Live-Status.

    ca. 830 von ca. 920 Commits

    • Rund 60 Lambda-Funktionen und 25 eigene GraphQL-Mutations über 21 Modelle
    • SQS-Worker-Pipeline mit DLQ und Reconciliation für Jobs mit ca. 3.500 Websites bei bis zu 140 parallelen Workern
    • Ein EventBridge-Schedule pro E-Mail, idempotent angelegt, mit einem Reconciler im 30-Minuten-Takt
    • Webhook-gesteuerte externe Jobs mit Polling als Fallback
    • Next.js 15
    • React 19
    • MUI
    • TanStack Query
    • AppSync
    • DynamoDB
    • Lambda
    • SQS
    • EventBridge Scheduler
    • S3
    • Cognito
    Zu den Engineering Stories

  • Formilo · Teamprojekt, 2025–2026, Lead Developer

    Coaching Planner CRM

    Verwaltet Coaches, Coachees, Abwesenheiten und Feiertage, Terminplanung und Kapazitäten, verschickt Stundenzettel und Rechnungen per E-Mail und exportiert nach PDF und Excel.

    ca. 70 % der Commits

    • Eigene „Day-first“-Planungs-Engine: ein Termin pro Tag, höchstens 3 Tage am Stück, strikt 1:1 pro Coach, Feiertage und Abwesenheiten berücksichtigt
    • Engine abgesichert durch rund 50 Vitest-Suites, darunter Golden-, Stress- und Kapazitätstests
    • Idempotente Lambda für Batch-Anlage mit verteiltem Lock auf DynamoDB-Basis (TransactWrite + TTL)
    • F&E-Erweiterung: LLM-basierte Planung als asynchroner Job (DynamoDB Stream → Lambda) mit OpenAI/DeepSeek als Provider und deterministischer Validierung der KI-Ausgabe
    • React 19
    • Vite
    • TypeScript
    • MUI
    • TanStack Query/Table
    • FullCalendar
    • Amplify Gen 2
    • Cognito
    • AppSync
    • DynamoDB
    • S3
    • Lambda

  • Kundenprojekt über Formilo, 2026, Full-Stack, allein

    Workflow-Plattform für Vertragsänderungen

    Release Candidate

    Löst bei einem deutschen Küchenhändler ein altes PDF-Formular ab, mit dem Vertragsänderungen erfasst und weitergeleitet wurden.

    • Rollenbasierter Workflow (Vertrieb, Innendienst, Admin) mit Rückgaben, Vertretungen und vollständiger Änderungshistorie
    • Serverseitige PDF-Erzeugung mit Playwright: interne und Kundenversion, versioniert
    • E-Mail-Outbox auf Postgres-Basis mit Retry-Workern und Archivanbindung
    • Security-Härtung (CSRF, Rate Limiting, verschlüsselte SMTP-Zugangsdaten), über 200 Server-Testdateien, CI, Docker Compose + Caddy
    • Node.js 24
    • TypeScript
    • Express 5
    • Prisma 7
    • PostgreSQL
    • React 19
    • Vite
    • Tailwind v4
    • TanStack Query
    • Playwright
    • Docker

  • ComonGames, 2024–2026, Frontend

    Sacralium – Landingpage & Shop

    Marketing- und Registrierungsseite für das Browser-MMORPG Sacralium mit Registrierung und Login über die Forum-API des Spiels, dazu ein statischer In-Game-Shop mit Zahlungsstatus- und Rechtsseiten.

    • Containerisiertes Deployment über GitLab CI
    • HTML
    • SCSS
    • JavaScript
    • Docker
    • GitLab CI
    sacralium.game (öffnet in einem neuen Tab)

  • Privates Projekt, 2024–2025

    Konnektor Kompass

    Kostenloser, nicht kommerzieller Trainer für deutsche Konnektoren und Präpositionen: Verben, Nomen und Adjektive mit Präpositionen.

    • Erhebt keine personenbezogenen Daten
    • React
    • Chakra UI
    • TanStack Query
    • Framer Motion
    konnektor-kompass.vercel.app (öffnet in einem neuen Tab)

  • Privates Projekt, 2026

    Medicina-Legale-Quiz

    Prüfungstrainer für italienische Fragen zur Rechtsmedizin mit russischen Übersetzungen, Lernfortschritt und Wiederholung falsch beantworteter Fragen.

    • Versionierter Fortschritt in localStorage mit Migrationen
    • Parser, der Quelltexte in Fragen-JSON umwandelt
    • React
    • Chakra UI
    med-quiz-tau.vercel.app (öffnet in einem neuen Tab)

Werdegang

Berufserfahrung

Von Frontend-Arbeit an Websites und Spielen bis zu Full-Stack-Systemen auf serverlosem AWS.

Berlin · offen für Remote-Arbeit

  1. – heute

    Software-Entwickler, Formilo, Berlin

    • Performante, skalierbare Webanwendungen mit React, Next.js und TypeScript auf serverloser AWS-Infrastruktur.
    • Modulare Frontend-Architekturen, Anbindung von REST-APIs und responsive UI-Komponenten mit MUI, shadcn/ui und Chakra UI.
    • Architekturentscheidungen, Feature-Planung und Deployment, einschließlich KI-gestützter Funktionen und automatisierter Workflows.
    • AWS
    • React
    • Next.js
    • TypeScript
    • Zustand
    • TanStack Query

  2. –

    Frontend Developer, ComonGames, Berlin

    • Moderne Frontend-Lösungen und komponentenbasierte Benutzeroberflächen.
    • Enge Zusammenarbeit mit Backend- und DevOps-Teams in agilen Prozessen.
    • Umsetzung und Optimierung von UI/UX.
    • React
    • Next.js
    • TypeScript
    • REST API
    • Material UI
    • Firebase
    • Git
    • Figma
    • WordPress

  3. –

    Frontend Developer, Adler Technologie, Berlin

    • Entwicklung und Optimierung von Webanwendungen, Systemintegrationen und Frontend-Lösungen.
    • Architektur-Meetings, Code-Reviews und Refactoring.
    • React
    • JavaScript
    • Node.js
    • Redux
    • HTML5
    • SASS
    • MySQL
    • Git

  4. –

    Frontend Developer, Forum Berufsbildung, Berlin

    • Analyse und Optimierung bestehender Websites sowie Frontend- und CMS-Aufgaben.
    • Technische Recherche zu Shop- und Plattformlösungen.
    • JavaScript
    • WordPress
    • REST API
    • HTML5
    • CSS3
    • Figma
    • Git

Ausbildung

  • –

    Web-Entwickler

    Tel-Ran Educational Center

  • –

    Fachinformatiker Anwendungsentwicklung

    Forum Berufsbildung e.V.

  • –

    B.Sc. Informationssysteme und Informationstechnologien

    Staatliche Universität für Informationstechnologien, Radiotechnik und Elektronik, Moskau

Sprachen

Deutsch
C1
Russisch
Muttersprache

Arbeitsweise

Prinzipien, nach denen ich baue

Schlussfolgerungen aus meinen eigenen Artikeln. Sie betreffen den Teil, den viele Demos auslassen – und der ein verteiltes System im Produktivbetrieb erst beherrschbar macht.

  1. 01

    Mit dem Retry rechnen

    Lambda wiederholt fehlgeschlagene Aufrufe, und meine Architektur muss darauf vorbereitet sein. Jeder Handler entscheidet bewusst, welche Fehler er wirft und welche er behandelt – und ein zweiter Lauf darf keinen Schaden anrichten.

  2. 02

    Abgleichen statt nur wiederholen

    Retries ersetzen keine Reconciliation. Ein regelmäßiger Abgleich vergleicht, was passieren sollte, mit dem, was tatsächlich passiert ist – damit eine verlorene Nachricht oder ein verpasster Schedule nicht verloren bleibt.

  3. 03

    Mutations koordinieren Workflows

    CRUD bildet Zustand ab, Mutations koordinieren Workflows. Der Browser bleibt für die Absicht zuständig, das Backend übernimmt die Orchestrierung.

  4. 04

    Echtzeit, mit Fallback

    Echtzeit, wenn es funktioniert, robust, wenn nicht. Für Live-Status setze ich zuerst auf Subscriptions und halte Polling als Fallback bereit, damit der Fortschritt auch bei abgebrochener Verbindung ankommt.

Texte

Artikel

Notizen aus der Entwicklung ereignisgetriebener Systeme auf AWS.

Alle Artikel auf LinkedIn (öffnet LinkedIn in einem neuen Tab)

Kontakt

Lassen Sie uns etwas Verlässliches bauen.

Ein System, das unter echter Last stabil bleiben soll, eine Idee für einen Artikel oder eine Rolle, über die wir sprechen sollten: Ich freue mich über Ihre Nachricht.

E-Mail schreiben

Gebaut mit Next.js 16, Tailwind CSS und CanvasGehostet auf VercelQuellcode auf GitHub Stand